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A Bulk Communications Process Using Multiple Delivery Media 
Related Application 

The present application claims the benefit of the earlier filing date of Australian 
5 Provisional Patent Application No. 2002950435 filed on 29 July 2002 in the name of 
Trade Wind Communications Ltd and having the same title, the contents of which are 
incorporated by reference herein. 

Field of the Invention 

1 0 The present invention relates generally to bulk communications and in particular to 
methods and systems for bulk communications using multiple delivery media. 

Background 

Businesses, companies, and organizations (simply originators hereinafter) use bulk 
1 5 communications with their clients, suppliers, and other parties (simply recipients 

hereinafter) for a variety of reasons. Typically, such bulk communications are carried 
out using one of the following media: Surface Mail, Email, Facsimile, and Short Message 
Service (SMS) messages sent to recipients' mobile phones. 

20 Originators of communications have different types of bulk communications with their 
recipients ranging from ad-hoc marketing communications through to recurring delivery 
of essential information such as invoices, statements, and reminder notices. Generally, 
these bulk communications have the following common elements: 

• A list of recipient information is provided separately, often needing to be 
25 extracted from a corporate database or accounting system; 

• A form of document template is used; 

• Data from the recipient list is merged, or overlaid, onto the template document; 
and 

• The final 'merged' document is delivered to the .customer. 

30 
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Communication with recipients can originate from different departments or entities of the 
originator and be carried out in different ways depending on the type of communication 
media being used. In carrying out these various communications, the originators use 
different interfaces and technology depending on whether originators are sending 
5 information out via Surface Mail, Email, Facsimile, or SMS. The originators may choose 
to host some or all of the technology required for the relevant communications in-house, 
but in other cases the originators may out-source the communications. 

Mail merge software applications exist for generating address stickers for envelopes and 
1 0 for merging and printing letters. Originators may also have proprietary systems and 
printing departments set up in-house to manage surface mail merging. Mailing houses 
provide originators with the ability to outsource their surface mailing requirements. 
Generally, customized scripts are written to map data extracted from the originators' 
databases and overlay the extracted data onto pre-printed paper stock. 

15 

Facsimile (fax) machines have the capability to store lists and do bulk message delivery. 
Depending on the size of the communication, bulk emailing can be carried out using 
tools such as Microsoft Outlook. This application enables a user to merge data fields of a 
data repository into a Microsoft Word document and then email a merged document to a 

20 recipient list via its mail merge tools. Other software applications beside Microsoft 
Outlook and Microsoft Word have similar functionality. For software solutions in this 
area, fax cards and fax print drivers, etc., must be installed on the network or the 
workstation that the software is installed. Businesses or companies also provide bulk fax 
and email services. Some require personalized documents for the different recipients to 

25 be supplied by the originators; others carry out merging of data for the originator. 
Enterprise Resource Planning (ERP) and accounting software may also support the 
capability to email or fax from within the application or software package. However, this 
is usually geared to individual communications (i.e., send a single email or fax from 
within the package at a certain point within a business process), rather than allowing for a 

30 bulk personalisation and delivery. 
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Originators may adapt their systems to issue SMS messages via a carrier. Usually, this is 
done using 'email to SMS* type services that enable an email to be sent to a specified 
address, formatted in a given manner, and then forwarded on as an SMS message to a 
mobile phone. Originators may enable the bulk outsourcing of SMS messaging, but 
5 generally do not provide a capability, or support provision by third party products of a 
capability to merge personalized data from the same database as the other delivery 
mechanisms. 

Limited, combined services exist, usually capable of forwarding emails to fax or to SMS. 
10 Amongst other things, these services do not provide formatting and merge functionality. 
Such services do not allow for specific formatting rules to be specified for the different 
delivery mechanisms whilst using the same recipient list and database, and do not 
support surface mail as one of the delivery options. 

1 5 MessagingDirect (from ACI) offers e-Courier. B-Courier I is a direct electronic billing 
and payment solution. These tools seek to combine traditional direct business-to- 
business paper transactions with the speed, efficiency and flexibility of electronic 
delivery. Both also attempt to facilitate a streamlined business process through direct e- 
business: digitally signed, legally binding and securely delivered end-to-end 

20 e-transactions, such as bills, statements, invoices, confirmations, policies. The entire 
business process aims to be online, enabling e-transactions to flow through an electronic 
channel directly between businesses and their customers, partners and suppliers. The 
MessagingDirect system does not support a unified interface for email, Fax or Surface 
Mail delivery. The MessagingDirect product requires all recipients to enrol with the 

25 service. 

MessageReach and Fax MailMERGE (from Xpedite) have different offerings for 
different media, but do not simultaneously personalize and deliver a single recipient list 
to multiple media 

30 
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Pulse Enterprise (from Esker Software) is another similar application, but does not 
incorporate escalation, is not offered as an ASP model (or as a Web Service), and does 
not support surface mail delivery. Pulse Enterprise also requires Fax cards, etc., to be 
installed along with the software. The company making use of Pulse Enterprise must 
5 install the software and hardware in their environment and manage Pulse Enterprise as 
well as all Fax, SMS, Email interfaces etc. Pulse Enterprise includes a General 
Document Recognition™ (GDR) component. General Document Recognition™ seeks 
to automate the conversion of text and print-stream data into multiple electronic formats 
and the processing and delivery of these documents to any receiving device. 

10 

Thus, a need clearly exists for an automated service that enables originators to use one 
bulk communications service with a single common interface and to re-use the same set 
of recipient data, so that bulk communications to recipients can be carried out via all 
existing, different media including Conventional or Surface Mail, Email, Fax and SMS 

1 5 (and any other new delivery media that might arise in the future). Further, a need clearly 
exists for an automated service that enables an originator to manage the delivery of 
messages to recipients based on each recipient's preference for receiving the information 
including how that information is delivered if unsuccessful on a first media, without the 
need for the originator to install and manage technology specific to a particular delivery 

20 type. Still further, a need exists for an automated service that can format and deliver data 
via a single interface to the full spectrum of delivery media (Fax, Email, SMS, Paper and 
Archiving) based on the recipients' preferences. 

Summary 

25 In accordance with a first aspect of the invention, there is provided a method for bulk 
communication of information to recipients via multiple delivery media including 
facsimile, email, surface mail, and SMS messaging. Preferably, this includes the ability 
to expand to other new media types in the future. Information for distribution including 
information regarding recipients is received via a single interface. The received 

30 information may include one or more template documents and data specific to each 
recipient (including embeddable image data). At least one document based on the 
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received information is transmitted using a specified one of the delivery media for each 
of the recipients based on the recipients' delivery preferences. 

Preferably, the method includes the step of escalating transmission of the at least one 
5 document using a different one of the delivery media for each of one or more of the 
recipients for whom transmission by the specified delivery media fails. The at least one 
document may be converted into a format suitable for the specified one or different one 
of delivery media for each recipient. The formatted document may then be sent to a 
carrier for transmission using the specified one or the different one of the delivery media. 
1 0 A report from the carrier regarding the transmission may be processed to provide status 
information regarding delivery of the document to each recipient. In turn, the escalating 
step may be dependent upon the status information. 

The method may further include the step of merging the one or more template documents 
1 5 and the data specific to each recipient (optionally including image data specific to each 
recipient) to provide the at least one document for each of the recipients. The method 
may also include the steps of determining a document template type for each delivery 
media and selecting a merging process for the document template type. The data specific 
to each recipient may be provided to the respective merging process. The delivery media 
20 may include archiving in order to facilitate recipient requests for additional copies of 
merged template documents at some time in the future. 

Further aspects of the invention include a system and a computer program product for 
bulk communication of information to recipients via multiple delivery media including 
25 facsimile, email, surface mail, and SMS messaging (and able to be extended to other new 
media types), based on the method described above. These and further aspects of the 
invention are described in greater detail hereinafter. 

Brief Description of the Drawings 

30 A small number of embodiments of the invention are described hereinafter with reference 
to the accompanying drawings, in which: 
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Fig. 1 is a detailed flow diagram illustrating a process for handling messages in 
accordance with an embodiment of the invention; 

5 Fig. 2 is a block diagram illustrating a services interface for three different access 
methods in accordance with the embodiment of the invention; 

Fig. 3 is a block diagram illustrating a pluggable data file converter in accordance with 
the embodiment of the invention; 

10 

Fig. 4 is a block diagram illustrating a document merger in accordance with the 
embodiment of the invention; 

Fig. 5 is a detailed flow diagram illustrating a process for handling preference rules for 
1 5 recipients and corresponding delivery media for each recipient in accordance with the 
embodiment of the invention; 

Fig. 6 is a detailed flow diagram illustrating a process for escalation processing based on 
recipient preferences in accordance with the embodiment of the invention; 

20 

Fig. 7 is a flow diagram illustrating a process for generating integrated reports in 
accordance with the embodiment of the invention; 

Fig. 8 is a screenshot of a user interface for recipients to specify delivery preferences in 
25 accordance with the embodiment of the invention; 

Fig. 9 is a block diagram illustrating concurrency and pipelining of merge and 
transmission processing in accordance with the embodiment of the invention; 

30 Figs. 10a - 10c are a listing of the recipient list XML schema in accordance with the 
embodiment of the invention; 
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Fig. 1 1 is a block diagram of a message distribution system in accordance with another 
embodiment of the invention; 

5 Fig. 12 is a block diagram of the system engine of Fig. 1 1 ; 

Fig. 13 depicts a template; 

Fig. 14 illustrates the redirection/escalation information contained within a recipient 
10 record; 

Fig. 1 5 is a table showing rules covering the functions of a Web interface; 
Fig. 1 6 illustrates a log on screen that may be practiced; 

15 

Fig. 17 illustrates an example of a main screen layout; 
Fig. 1 8 illustrates an administration panel for viewing a user; 
20 Fig. 19 illustrates an enterprise interface job submission screen; 
Fig. 20 illustrates an example of a status report; 
Figs. 21 A and 21B illustrates a job configuration panel; 

25 

Fig. 22 illustrates a file containing the definition of a messaging job to be submitted by 
the FTP interface; 

Fig. 23 is a block diagram of the architecture of the message distribution system; 

30 

Fig. 24 illustrates an example of a recipient file in XML format; 
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Fig. 25 is an entity relationship diagram of the database structure; 

Fig. 26 shows an example of the configuration parameters for a paper job; 

5 

Fig. 27 shows an example of one type of resource in a Java_Mapping u _Class_Resource 
record; 

Fig. 28 is a block diagram showing the flow of job execution; 

10 

Fig. 29 is a block diagram of a system comprising a bulk interface, a web interface, and a 
common interface; and 

Fig. 30 shows a recipient list XML schema. 

15 

Detailed Description 

Methods, systems, and computer program products are disclosed for bulk communication 
of information to a single set of recipients via multiple delivery media based on the 
recipients* delivery preferences and incorporating escalation. Preferably, the method, the 

20 system and the computer program enable a service that is delivered as a Web Service. 
Further, the delivery media include Surface Mail, Email, Encrypted Email, Facsimile, 
SMS, and Archiving (and caters for inclusion of other media types in the future. In the 
following description, numerous specific details are set forth including communications 
networks, communications protocols, data formats such as MHTML, Postscript, and the 

25 like. However, it will be apparent to those skilled in the art that, in the light of this 

disclosure, modifications and/or substitutions may be made without departing from the 
scope and spirit of the invention. In other instances, details well known to those skilled 
in the art may be omitted so as not to obscure the invention. 

30 The terms "escalation", "escalate", "escalating" and other forms of the word "escalate" 
mean re-directing in the context of this document. Thus, the phrase "escalating 
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transmission of at least one document using a different one of the delivery media" means 
that the transmission is re-directed using another media. 

The recipient specifies, amongst other things, by which medium, delivery of information 
5 is preferred. Further, the recipient is able to specify the media by which information is to 
be delivered if the delivery cannot be achieved using the preferred media. Thus, in the 
event of delivery failure, the escalation to different media is according to the recipients' 
preferences. Preferably, the process is implemented using computer software that has 
been developed in an object-oriented manner, made up of multiple sub-components. The 
10 user interface to the software is preferably delivered as a web service. More preferably, 
the software application is written in Java and the extensible Markup Language (XML). 
A general overview is provided immediately hereinafter, followed by a more detailed 
description of an embodiment of the invention with reference to the drawings. 

1 5 Some portions of the following description are explicitly or implicitly presented in terms 
of algorithms and symbolic representations of operations on data within a computer 
memory. These algorithmic descriptions and representations are the means used by those 
skilled in the data processing arts to most effectively convey the substance of their work 
to others skilled in the art. An algorithm is here, and generally, conceived to be a self- 

20 consistent sequence of steps leading to a desired result. The steps are those requiring 
physical manipulations of physical quantities. Usually, though not necessarily, these 
quantities take the form of electrical or magnetic signals capable of being stored, 
transferred, combined, compared, and otherwise manipulated. At times principally for 
reasons of common usage, these signals are conveniently referred to as bits, values, 

25 elements, symbols, characters, terms, numbers, or the like. 

However, the above and similar terms are to be associated with the appropriate physical 
quantities and are merely convenient labels applied to these quantities. Unless 
specifically stated otherwise, and as apparent from the following, it will be appreciated 
30 by those skilled in the art that passages herein utilizing terms such as "computing", 
"merging", "calculating", "converting", "determining", "comparing", "generating", 
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"selecting", "outputting", or the like, refer to the action and processes of a computer 
system, or similar electronic device, that manipulates and transforms data represented as 
physical (electronic) quantities within the registers and memories of the computer system 
into other data similarly represented as physical quantities within the computer system 
5 memories or registers or other such information storage, transmission or display devices. 

The present specification also discloses apparatuses for performing the operations of the 
methods. Such an apparatus may be specially constructed for the required purposes, or 
may comprise a general-purpose computer or other device selectively activated or 

10 reconfigured by a computer program stored in the computer. The algorithms and 

displays presented herein are not inherendy related to any particular computer or other 
apparatus. Various general-purpose machines may be used with programs in accordance 
with the teachings herein. Alternatively, the construction of more specialized apparatus 
to perform the required method steps may be appropriate. For example, an Internet 

15 Directory Server computer may be configured to populate a directory stored thereon by 
installing computer programs for performing the calculations, comparisons and selection 
steps described below. 

Further, the present specification also discloses computer program products including a 
20 computer readable medium having a computer program for performing the operations of 
the methods stored thereon. The computer readable medium is taken herein to include 
any transmission medium for communicating the computer program between a source 
and a destination. The transmission medium may include storage devices such as 
magnetic or optical disks, memory chips, or other storage devices suitable for interfacing 
25 with a general-purpose computer. The transmission medium may also include a hard- 
wired medium such as exemplified in the Internet system, or wireless medium such as 
exemplified in the GSM mobile telephone system. The computer program is not 
intended to be limited to any particular programming language and implementation 
thereof. It will be appreciated that a variety of programming languages and coding 
30 thereof may be used to implement the teachings of the disclosure contained herein. 
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Where reference is made in any one or more of the accompanying drawings to steps 
and/or features, which have the same reference numerals, those steps and/or features 
have for the purposes of this description the same functions) or operation^), unless the 
contrary intention appears. 

5 

For ease of reference, the description is set forth hereinafter with the following 
subheadings: 

A. FIRST EMBODIMENT 

I. Overview, 
10 n. Message Processing* 

HI. Service Interfaced), 

IV. Pluggable Data File Converter, 

V. Document Merger, 

VI. Preference Rules Process, 
15 VTI. Transmitters, 

VIII. Carrier Interfaces, 
DC Escalation Processor, 

X. Reporting, 

XI. Concunency/Pipelining of Merge/Transmission. 

20 

B. SECOND EMBODIMENT 

I. Overview, 

II. Concepts, 

III. The Web Interface, 
25 IV. System Architecture, 

V. Data File Structures, 

Vn. The Database Structure, 

VOL Java Mapping Classes and XSL Templates. 
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A. First Embodiment 
I Overview 

Significant aspects of the bulk communications process and system in accordance with 
an embodiment of the invention include: 
5 • An originator can carry out bulk communication with recipients using one 

service, via a single interface and using a single recipient list, but can deliver via 
all currently available media including Conventional (Surface) Mail, Email 
(encrypted and non-encrypted), Fax and SMS, as well as delivery of documents to 
a hosted Document Archiving and Retrieval system (and ability to expand to 
1 0 other media technology in future). 

• Delivery preferences can be specified for individual recipients, as well as 
escalation rules. So for example, a recipient can specify that the recipient prefers 
to receive communications via Fax, but that information is preferably received by 
Surface Mail if the Fax fails. This can be done at an individual recipient level as 

1 5 well as at an overall level. 

• There is one Application Programming Interface (API) into the system. Via this 
one API, delivery can be carried out using any of Fax, Email, Encrypted Email, 
SMS, Surface Mail and Archiving (and other future media types when available). 

• The process has been designed in a componentised manner to cater easily for the 
20 integration of future types of delivery media (e.g. WAP, other Wireless etc.) 

• A single recipient list can be used for delivery to all of the different target media. 
The recipient list can be in any format and the process converts the list into XML. 
A variety of input recipient file formats are supported and data conversion is 
carried out to XML format 

25 • Merging (personalization) can be carried out using fields within the recipient list 
for all of the different delivery media. This includes personalization of SMS text 
messages, email body and subject text, as well as document merge for Word, 
Portable Document Format (PDF), Hyper-Text Markup Language (HTML) and 
MIME-HTML (MHTML). MIME stands for Multipurpose Internet Mail 
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Extensions. Document merging is supported using state of the art XML document 
formats and XSL and XSL-FO style sheets for data formatting and presentation. 

• The service manages all interfaces to carriers, including surface-mail mailing 
houses and to a hosted archiving service. Software need not be installed or 

5 managed at the originator. Different carriers may be supported for the same media 

type, and the originator can specify their preferred carrier. 

• Integrated reporting of delivery results, including reporting on escalations that 
have occurred and the success/failure for all recipients across different media 
types is provided. An integrated reporting interface is provided that enables a 

1 0 user to view the messaging and escalation status of individual recipients. 

• The process is designed for the 'bulk mailing' scenario where a large number of 
recipients are being targeted, in an analogous manner to the way in which large 
numbers of recipients are targeted by conventional surface mail mailing houses. 

The process or system utilizes one or more of the following techniques to provide 
features not found in other messaging services: 

• The process recognizes the common elements required in communications with 
recipients and encapsulates those elements in an XML document. These elements 
include a recipient's delivery preferences and a set of escalation criteria. The 
delivery preferences and escalation criteria are specified using a shorthand 
notation. A proprietary XML schema is also defined to describe the XML 
document format. 

• The process provides a remotely accessible and secure electronic interface or 
common interface. The single Application Programming Interface (API) supports 
all forms of messaging in a consistent manner. The common interface can be 
accessed by either the File Transfer Protocol (FTP) or Simple Object Access 
Protocol (SOAP). The interface can also be accessed via a Web user interface. 

• The service provides data merging (personalization) capabilities enabling the 
service to merge recipient data into a variety of document formats including PDF, 
HTML, MHTML, Microsoft Word, and Text The service preferably uses an 
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eXtensible Stylesheet Language Formatting Objects (XSL-FO) formatting engine 
to cany out the data merging. The personalization capability includes the ability 
to personalize the subject line and body text of email messages as well as 
messages being sent via SMS. 

5 • The API supports a mechanism for specifying a data converter. The service has 
special code built in that enables customized data converters to be written and 
plugged in dynamically. The data converters take the recipient data in any format 
(i.e., as extracted from an organisation's accounting or ERP systems) and convert 
the recipient data into a common XML format for feeding into the messaging 

10 engine. 

• The service manages all of the following carrier interfaces: SMS, Email, 
Encrypted Email, Fax, Conventional (Surface) Mail and Archiving. This is done 
by having a separate code layer in the system that presents a common carrier 
interface to the rest of the messaging engine. This also enables future media 

1 5 types to be easily incorporated into the service (e.g. WAP). The service can also 

store preferences that the originator may have regarding the choice of carrier. 

• The service re-uses the one single set of input data for all of the different 
document-template and delivery-media types. The service does this by carrying 
out the document merging in one module or component, and the formatting for 

20 presentation to the carrier interface in a separate module. 

• The service provides a single, integrated reporting interface to the user by taking 
the different types of reports that are received back from the carriers and 
converting the reports into a common format for storage in a relational database. 
The service then reconciles these delivery reports against the individual 

25 messaging recipients in order to track delivery and drive the escalation 

procedures. This enables the service to provide reports to the user on the success 
and failure of individual messages and show the escalation path that has been 
taken for individual recipients. 

• The service has been implemented in a manner that enables a high volume of 
30 messaging throughput. The service does this by breaking out the steps in the 

messaging process into different components. These components are then 
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executed concurrently, so that many different steps are being executed 
simultaneously. 

II. Message Processing 

5 Fig. 1 illustrates diagrammatically the messaging process 1 00 that can be implemented in 
software. Processing commences in step 102. A recipient data file 106, 
jobDescriptor.XML 108, and template documents 1 10 are received via the API at step 
104. The details of jobDescriptor.XML 108 are described in detail hereinafter. In step 
1 12, the job parameters are processed and the data file is input. In step 1 14, a check is 

10 made to determine if the data converter has been specified. If step 114 returns true 
(YES), processing continues at step 1 16 and the custom converter that was specified is 
loaded. In step 1 1 8, the data is converted to XML using the custom converter, and 
processing then continues at step 120. If step 1 14 returns false (NO), processing 
continues at step 120. 

15 

In step 120, the XML recipient list is validated and parsed, and then stored to a database. 
This produces stored recipient data and delivery preferences 122. In step 124, recipient 
delivery preferences are processed and broken up into bundles for different media types. 
In step 126, a check is made to determine the document template types for each media 
20 type and a corresponding document merger is selected. The Document Template is the 
same for all recipients for a specific media type. The Document Merger takes each 
individual recipient's data and merges that data into the document template to produce a 
personalized document for that recipient. The Document Template may be an XSL 
template. Alternately, MS Word Templates and HTML Templates are supported. This 

25 is the 'Template Type' . Depending on the template type, a different document merger (an 
XSL-FO Merger, an MS Word Merger, a HTML Merger etc.) is loaded. From step 126, 
one or more of several merge steps or operations may be performed. The merge steps 
include text merge 128, PDF merge 130, Postscript merge 132, HTML merge 134, and 
Microsoft Word merge 136. It will be appreciated by those skilled in the art, in the light 

30 of this disclosure, that other types of merges may be practiced without departing from the 
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scope and spirit of the invention. Recipient data 138 is provided to the merge steps 128- 
136. 

From each of steps 128-136, processing continues at step 140. In step 140, a check is 
5 made to choose delivery carriers for recipients. This is done by re-examining the 

outcome of the previous Process Recipient Delivery Preferences step 124 in combination 
with the preferred carrier for each media configured for the originator of this Job. The 
combination of these two pieces of information is used to decide on the carrier modules 
to use. If a fax is to be sent, processing continues through the path including steps 142- 
10 144. If an email is to be sent, processing continues through the path including steps 148- 
1 52. If surface mail is to be sent, processing continues through the path including steps 
154-158. If an SMS message is to be sent, processing continues through the path 
including steps 160-164. If the document is to be archived, processing continues through 
the path including steps 166-170. 

15 

For the fax path, the merged document is converted to a bitmap format, which is 
preferably TIFF in step 142. In step 144, the TIFF format document is sent to a fax 
carrier for transmission. In step 146, a fax carrier report that is generated is processed 
and parsed. The status of the transmission is set on the recipient list. Processing then 
20 continues at step 1 72. 

For the email path, the merged document is converted in step 148 to MHTML format, if 
necessary. Often, conversion to MHTML is not required because the document remains 
as a PDF, HTML or Microsoft Word Attachment. In step 1 50, the email message 
25 containing the document either as an attachment or as embedded MTHML, is sent to an 
email carrier for transmission. In step 152, an email carrier report that is generated is 
processed and parsed. The status of the transmission is set on the recipient list. 
Processing then continues at step 172. 

30 For the surface mail path, the merged document is converted in step 154 to the Postscript 
format, if necessary. In step 156, the Postscript format document is sent to a 
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conventional surface mail carrier for transmission. In step 158, a surface mail carrier 
report that is generated is processed and parsed. The status of the transmission is set on 
the recipient list Processing then continues at step 172. 

5 For the SMS message path, the merged document is formatted in step 1 60 for SMS, if 
necessary. In step 162, the SMS format document is sent to an SMS carrier for 
transmission. In step 164, an SMS carrier report that is generated is processed and 
parsed. The status of the transmission is set on the recipient list. Processing then 
continues at step 172. 

10 

For the archiving path, the merged document is formatted in step 166 for archiving, if 
necessary. This format is generally PDF or Postscript, however no particular format is 
mandated by the archiving system and so the format is dependent on the originator's 
preferences. In step 168, the formatted document is sent to the archiving system. In step 
15 1 70, a report that is generated by the archiving system is processed and parsed. The 
status of the transmission is set on the recipient list. Processing then continues at step 
172. 

In step 172, escalations are processed, if necessary, dependent on the recipient list status 
20 and delivery preferences 176. In step 178, a check is made to determine if any 

escalations are required. If step 178 returns true (YES), processing continues at step 124 
in respect of the recipients for whom escalation occurs. Otherwise, if step 178 returns 
false (NO), processing terminates in step 180. 

25 The software architecture used to provide the process 100 of Fig. 1 is depicted in the 
class diagram of Figs. 1 1 and 1 1 A-l 1M of Australian Provisional Patent Application 
No. 2002950435, which is incorporated by reference. In Australian Provisional 
Application No. 2002950435, Fig. 11 depicts the arrangement of the portions in 
Figs. 1 1 A-l 1M. The class diagram provides a detailed description of the application 

30 architecture and the components that make up the application. The components include 
escalation processing, status processing, job submission and processing, merging, 
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formatting and carrier transmission. The schema communicates several aspects of the 
architecture. 

Additional aspects of this process are described in detail hereinafter. 

5 

TTT Service Interfaced 

The embodiment of the invention is preferably provided as a hosted service, commonly 
known as the Application Service Provider (ASP) model. Preferably, three .different 
access methods are used for accessing the hosted service and are supported by three 
1 0 different interface components, respectively. The services interface 200 is depicted in 
Fig. 2 including a Web Services Interface (SOAP) 210, an FTP interface 212, and a Web 
Graphical User interface (Browser/HTML based) 214. The three external interface 
components 210, 212 and 214 all utilise the same underlying common interface 
component 216, which is preferably XML. 

15 

A Web Service is a formal interface described by the Universal Description, Discovery 
and Integration (UDDI) and Web Services Definition Language (WSDL) standards. The 
hosted service provides an interface 210 that conforms to this standard. FTP (File 
Transfer Protocol) is a common protocol for transferring files over the Internet. The 
20 hosted service provides the FTP interface 212, because this interface 212 is a commonly 
understood interface that is easy for originators to access. The Web Graphical User 
interface 214 is provided to enable originators to submit jobs manually via a graphical 
user interface. 

25 The various interfaces 21 0, 212, 214 are lightweight and marshal data into a common 
format for submission to an underlying common interface 216 as shown in Fig. 2. The 
interface parameters are passed as XML. An XML Schema has also been defined to 
describe a job. This schema provides a mechanism for providing different document 
templates for different media, and also for specifying other preferences for a particular 

30 job. The format of this common XML Job Description File (' JobDescriptor' XML) 108 
of Fig. 1, including important tags within this XML schema, is set form in Table 1. 
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TABLE1 



Tag Description 

<job_type> The job_type tag allows for an overall job type to be set which 

defines the media via which all recipients are sent messages. 
This tag takes precedence over the transmission_rules tag, 
which is intended for use with the impending escalation 
functionality, allowing for a set of transmission rules to be 
supplied as escalation rules at a job level rather than at the 
recipient level. 

Supported job types include: 
<job_type>FAX ONLY</jobJype> 
<jobJype>EMAlL ONLY</job_type> 
<job_type>FAX AND EMAIL<7job_type> 
<job_type>FAX AND EMAIL AND SMS<job_type> 
(. . . etc - all combinations of media are allowed) 
<job_type>LIST PREFERENCES] ob_type> 

The LIST PREFERENCE job type uses the transmission rules 
set at a recipient level. See description of the 
RecipientData.xml for more details. 

<transmission_rules> The transmission_rules tag allows for a set of transmission 

rules to be defined at the job level These rules are applied to 
all recipients for that particular job, e.g., 
<transmission_rules>f:e</transmission_rules> 

<fax_tempiate> The fax template tag allows a template to be defined for 

documents produced for the purpose of fax transmission, e.g., 
<faxJemplate>AcmeRelativeImage.xsl</fax_template> 
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<paper_template> 



<email_body_template> 
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The email template tag allows a template to be defined for 
documents produced for the purpose of email transmission, 
e.g. 

<^maO_template>AcmeRelativeImage.xsl</email_template> 
The paper template tag allows a template to be defined for 
documents produced for the purpose of sending via snail mail, 
e.g., 

<paper_template>AcmeRelativeImage.xsKpaper_Jemplate> 
The email body template allows for a text email body to be 
included which are sent to all recipients receiving messaging 
via the email media. This tag contains text data that is 
included as the email body. The tag may contain merge fields 
that are defined <<ff_(merge_fieid_name)». The merge field 
tags are created by holding down the alt key and typing 01 7 1 
to create « and 0187 to create », e.g., 
<email_body_template> 
Dear «ff_firstname», 

Please find included your statement for the month of 
«ff_month». 

Regards 

«ff_creditmanager» 
</email_body_template> 
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<email_subject_template> The email subject template allows for a text email subject to 

be included that is sent to all recipients receiving messaging 
via the email media. This tag contains text data that are 
included as the email subject. The tag may contain merge 
fields that are defined «ff_(mergejield_name)». The merge 
field tags are created by holding down the alt key and typing 
0171 to create « and 0187 to create », e.g., 
<email_subj ect_template> 

Please find included your statement for the month of 
«ff_month>>. 

</emaiLsubject_template> 

The email subject template allows for an SMS message body 
to be included to be sent to recipients. This tag contains text 
data that is sent as the SMS body and may contain merge 
fields that are defined «ff_(merge_field_name)». The merge 
field tags are created by holding down the alt key and typing 
0171 to create « and 0187 to create », e.g., 
<sms_template> 

Your statement for the month of «ffjnonth» has been emailed 
to (dBF^emailaddress)). 
</sms_template> 

The associated image tag allows for the inclusion of 0-n 
images which may be required as part of a document merge, 
e.g. <associated_image>Acme.gif</associated_image> 
The recipient list tag defines the recipient data that is used to 
supply all recipient details and merge data. See description of 
RecipientData.xml for more information. E.g., 
<recipient_list>AcmeSmall.xmKrecipient_list> 



<sms_template> 



<associated_image> 



<recipient_list> 
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IV. Pluggable Data File Converter 

Originators using the hosted service submit a file containing information about the 
recipients being targeted as part of a particular bulk communication. These files may be 
extracts from an internal database or accounting system of a business, organization, etc. 

5 The embodiment of the invention standardises on XML input files, and thus data 

conversion 300 converts the recipient list file 310 into XML 314 as shown Fig. 3. For 
example, the recipient list file 3 1 0 may be a text or flat file. This done using a data file 
converter 312, which is preferably a component that enables customized converters to be 
plugged into the underlying platform. The conversion of the input files is then 

10 transparent to the user of the service. In the embodiment of the invention, data 
conversion is implemented as follows: 

• A Java interface is defined called CustomMapperlnterface 

• The Java interface has the following method defined: 

ComertFile(Hashmap hm, Destination d) 
15 • The JobDescriptor.xml input file has a * CustomJavaMapping' tag that 

indicates whether a custom mapper is to be used, a < CustomJavaClassName' 
tag, whereby a conversion Class can be specified, and * JavaMappingFile' tags 
whereby a keyed set of file names can be specified. 

• The Job processing engine uses Java's reflection capability to instantiate the 
20 Custom Java Converter Class and passes the JavaMappingFile parameters to 

the Custom Java Converter class in a Hashmap. 

• The Custom Java Class then processes the file parameters and generates the 
converted file. 



25 V. Document Merger 

The embodiment of the invention formats data for delivery to different types of media. 
Fig. 4 illustrates how document merging 400 is accordingly handled. The XML recipient 
list 410 (corresponding to the list 3 14 of Fig. 3) and an XSL or XSL-FO template 412 are 
provided to a document merger module or component 414 to produce the document 416 

30 in a desired format, preferably PDF or HTML. To carry out this presentation formatting, 
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the XSL and XSL-FO standards are used for defining the rules for formatting and 
presentation of XML data. The document merger module or component 414 applies the 
chosen XSL or XSL-FO template 412 to the underlying XML recipient list 410 to 
produce the PDF or HTML document 416 for transmission to the client. 

5 

To enable a single recipient list to be used for merging (personalization) and delivery of 
data to a variety of different media, based on the recipients* delivery preferences, a 
special XML recipient list schema 1000 has been defined and is illustrated in Figs. 10a, 
10b, and 10c. While a specific schema is set forth in Fig. 10, it will be appreciated by 
1 0 those skilled in the art, in the light of this disclosure, that modifications and/or 

substitutions may be made to the schema without departing from the scope and spirit of 
the invention. The schema 1000 is broken into two major sub-sections: 

1 . A transmission-rule-set that describes the addressing and preference criteria for a 
recipient for the different media. 
15 2. A recipient-data section that contains data to be merged into the document being 
transmitted. The recipient-data section can be structured according to our XML 
schema. Alternatively, there is provision for an XML-data sub element type that 
allows originators to structure this part of the recipient-data according to an XML 
schema of their own. 

20 

VI. Preference Rules Process 

The embodiment of the invention allows preference rules, including complex ones, to be 
specified for individual recipients using a specified notation for defining the preference 
rules. For example, the embodiment of the invention utilises the following notation (F:S- 
25 P) to mean send a Fax and an SMS, and if both of these fail, send by Surface Mail 
(Paper) instead. Preferably, a user interface is used for selecting delivery preferences, 
and a shorthand notation is used for specifying delivery preferences. The rules notation 
for delivery media types are set forth in detail in Table 2. 
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TABLE 2 



Media 



Notation 



Fax 



Forf 



Email 



Eore 



SMS 



Sors 



Paper 
Voice 
Archiving 



Porp 
Vorv 



A or a 



Encrypted Email (cipher) 
New Media Types to be 
determined 



Core 



10 



To cater for precedence rules and also the ability to combine more than one media type 
into a rule, several operators are used. A list preference is specified as a series of rules, 
separated by a dash (-). The dash (-) indicates that if the previous rule fails, use the next 
rule. A rule can be as simple as specifying a single media type (e.g., F for Fax) or a 
string of media types separated by the plus (+) or colon (:) operators, described 
hereinafter. Parentheses '(* T are used to encapsulate rules that involve more than one 
media type. 

An example of a simple precedence rule demonstrating the use of the dash (-) operator is: 



This rule denotes send an Email (rule 1). If rale 1 foils (e.g. if no email address is 
specified), then send a Fax (rule 2). If rule 2 fails, then send the item via paper-based 
media (rule 3). 



E-F-P. 



(1) 



BNSDOCID: <WO____2004O1210flA1 IA> 



WO 2004/012109 



PCT/AU2003/000954 



-25- 

If two media types are separated by a plus (+) operator, this denotes send the information 
to both of those particular media types (no precedence order). The rule fails if neither 
can be sent to. For example, the rule (F+E) indicates to try to send both an email and a 
fax. The rule fails if neither a fax number nor an email address is provided. 

5 

An example of the combination of the plus (+) operator and the precedence operator (-) 

is: 

(E+F)-P. (2) 
This rule denotes send both a fax and an email. If neither of these media succeed (e.g., 
10 because a fax number and a email address are not specified), the dash (-) operator comes 
into play and processing moves to the next rule, which denotes to send the document by 
Paper. 



If two media types are separated by a colon (:) operator, this denotes to send to both of 
1 5 the particular media types (no precedence order; i.e., same as the plus(+) operator). 
However, the rule foils if one of the media is not able to be sent to. For example, (F:E) 
denotes to try to send both an email and a fax. The rule fails if either the fax number or 
an email address is not provided. An example of a combination of the colon (:) operator 
and the precedence operator (-) is: 
20 (E:F>P. (3) 

This rule denotes to send both a fax and an email. If either media fails (e.g, because 
neither a fax number nor an email address is specified, the dash (-) operator comes into 
play and processing moves to the next rule, which denotes to send the document by 
Paper. 

25 

The precedence order for the various operators is as follows: 0, +> • » The parenthesis 
is evaluated first, the plus (+) operator is evaluated before the colon (:), which are all 
evaluated before the dash (-). An example illustrating a complex rule, utilizing all of the 
different operators and showing how the precedence rules work, is: 
30 (E:F+S)-(P:V). (4) 
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In this scenario, the parentheses take precedence, so the rule (E:F+S) is evaluated first. 
The plus(+) follows in preference to the parentheses, so the rule F+S is evaluated next. 
This denotes to send the information to both Fax and SMS. The * is evaluated next, so 
the rule E : "F+S" is the next thing to be evaluated. This denotes to send the information 

5 to both email and "F+S" (which denotes to send to Fax and SMS). The information is 
sent to all three of email, fox and SMS. If there is a failure of the rule (F+S), this is 
because both the fax and SMS failed. A failure of the rule E:"F+S" occurs because either 
the email or the "F+S" foiled. If the whole first rule E:"F+S" fails, the dash (-) comes 
into play and the next rule comes into effect (P:V). This rule (P:V) denotes to send the 

10 information to both Paper and Voice. In summary, the rule of Example (4) denotes to 
send the information to Email, Fax and SMS media. If either the email foils (e.g., no 
email address specified), or both the SMS and Fax fail (e.g., no SMS and fax numbers), 
then the information is sent to both Paper and Voice. 

15 In the embodiment of the invention, a user interface component or module allows quick 
entry of simple delivery combinations while at the same time providing the option of 
entering complex rules. The user interface component 800 shown in Fig. 8 is entitled 
broadcast options and contains several tick boxes 802 for each media type, including fax, 
email, SMS, voice, and paper. Radio buttons 804 are also provided to send to all and use 

20 list preference. A user can specify a rule to override the list preference in box text entry 
806(e.g.,(E+S>F-P). 

The preference rules processor interprets the recipient preferences and determines for 
each recipient what delivery media to send to. Fig. 5 shows a method 500 for handling 

25 the preference rules. Recipient data 5 1 0 in the XML format is provided to step 5 1 2, 
which loads preference rule data for the first, or next, recipient as the case may be. In 
step 514, processing starts from the position that any previous processing finished. In 
step 5 16, a check is made to determine if any more characters remain for processing. If 
step 5 16 returns false (NO), the current round of rule processing terminates in step 548. 

30 Otherwise, if step 5 1 6 returns true (YES), processing continues at step 5 1 8. 
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In step 5 1 8, an execution branch is performed dependent on the character representing a 
precedence operator or media notation. If step 518 determines or ")", processing 
continues at step 520. In step 520, a check is made to determine what parenthesis type is 
involved. If a "(" is determined in step 520, processing continues at step 522 and an open 
5 parenthesis is recorded. Otherwise if a ")" is determined in step 520, processing 
continues at step 524. In step 524, a close parenthesis is recorded and a group for the 
previous rule set is created. From each of steps 522 and 524, processing continues at step 
516. 

10 If step 518 determines the current character is a letter (F, E, S, P, A, C), processing 

continues at step 526. In step 526, a check is made to determine if the letter is F, E, S, P, 
A, or C, If step 526 returns F, processing continues at step 528 and the recipient is added 
to the fax list. If step 526 returns E, processing continues at step 530 and the recipient is 
added to the email list. If step 526 returns C, processing continues at step 532 and the 

1 5 recipient is added to the encrypted email list If step 526 returns P, processing continues 
at step 534 and the recipient is added to the surface mailing (paper) list. If step 526 
returns S, processing continues at step 536 and the recipient is added to the SMS list. If 
step 526 returns A, processing continues at step 538 and the recipient is added to the 
archiving list. From each of steps 528, 530, 532, 534, 536, and 538, processing continues 

20 at step 516. 

If step 518 determines the current character is an operator ":",."+", or processing 
continues at step 540. In step 540, a check is made to determine which operator is the 
current character. If step 540 returns processing continues at step 542 and the 
25 position after the symbol is record. Processing then proceeds to step 548. If step 540 
returns processing continues at step 544 and (OR) operator is recorded. 
Processing continues at step 5 16. If step 540 returns "+", processing continues at step 
546 and (AND) operator is recorded. Processing then continues at step 5 1 6. 
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VII. Transmitters 

The transmitters carry out final conversion of data for presentation to the carrier 
interface. For example, for faxing, a PDF document output from the document merger 
process is converted into a Tiff file for presentation to a fax carrier. The system allows 
5 different transmitters to be plugged in where appropriate for different carriers. 

Vin. Carrier Interfaces 

The carrier interfaces carry out final data conversion and batching into a carrier-specific 
file format for transmission to the chosen carrier for that particular media type. 
1 0 Alternative carriers may be plugged in for the different carrier interfaces, and the choice 
of carrier may be dynamically configured as part of an originator's user profile. 

IX. Escalation Processor 

The escalation process checks for a response from the carrier interfaces and parses the 
1 S results of the transmission for each recipient. If a transmission fails, the escalation 
process uses the recipients' preference rules (via the preference rules processor) to 
determine whether to retry the communication via a different media, and manages the 
activity of re-scheduling the transmission of data via the different media. The flow 
diagram in Fig. 6 illustrates escalation processing 600 and in particular how the 
20 escalation rules for Email work (Email being the most complicated). For the other media 
types, the escalation is simply based upon success/failure reports received back from the 
carrier. 

In Fig. 6, processing commences in step 610 in which an attempt is made to send email to 
25 the carrier. In step 61 2, a check is made to determine if an error occurred due to an 

unknown SMTP server. If step 612 returns true (YES), processing continues at step 624. 
If step 612 returns false (NO), processing continues at step 614. In step 614, a check is 
made to determine if the bounced email arrived in the originator's (client's) inbox at the 
hosted service (Emdirect). If step 614 returns true (YES), processing continues at step 
30 622. In step 622, the originator manually indicates that the email delivery failed for the 
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recipient This is preferably done via a web interface. Processing then continues at step 
624. If step 614 returns false (N)), processing continues at step 616. 

In step 616, a check is made to determine if the email opening timeout has expired. If 
5 step 616 returns false (NO), processing continues at step 618. In step 618, processing 
waits until the timeout expires and then processing proceeds to step 616. If step 616 
returns true (YES), processing continues at step 620. In step 620, a check is made to 
determine if email tracking shows that the email has been opened. If step 620 returns 
true (YES), processing terminates in step 632 and escalation is not performed. If step 
10 620 returns false (NO), processing continues at step 630. 

In step 624, a check is made to determine if the originator's approval is required for 
escalation. If step 624 returns false (NO), processing continues at step 630 and 
escalation to the next media type occurs. Otherwise, if step 624 returns true (YES), 
1 5 processing continues at step 626. In step 626, a check is made to determine if originator 
approval has been given. If step 626 returns false (NO), processing continues at step 
628. In step 628, manual originator approval event is awaited via web interface. 
Processing then continues at step 626. If step 626 returns true (YES), processing 
continues at step 630. Further details of this process are set forth hereinafter. 



The escalation processing provides the following functionality: 

• The ability to provide escalation functionality as an optional extra (configured at 
a user level) and charge accordingly. 

• The ability at a Job level to specify whether or not escalation is required for a 



• When "List Preference" is chosen on Job Submission, the ability for escalation to 
work according to a recipient's delivery preferences. 

• If a broadcast choice other than "List Preference" is used, the ability for 
escalation to follow the choice specified (e.g. email + Fax + Paper first tries to 



20 



25 



particular job. 



30 



email the recipient, then if that fails goes to fax, and then if that fails goes to 
paper). 
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• The ability for an originator to manually intervene in the escalation process and 
manually indicate which escalations are to proceed or not. 

• The ability for a user to manually flag emails as requiring escalation (so 
originators can see the bounces that arrive and then go to the web site and mark 

S those as requiring escalation). 

For the different media types, the escalation criteria are as follows. For some of the 
media types, alternative mechanisms have been described. Where alternatives are 
available, the originator has the choice of which escalation criteria the originator would 
1 0 like to apply. This is configured as part of the originator' s user preferences. 

If fax was not able to be sent after the prescribed number of retries, escalation may occur. 
This can be due to a variety of reasons, from an invalid fax number, through to a network 
difficulty (NCN) connecting to the specified fax machine. 

15 

If email is not tracked as opened by the recipient within the prescribed number of days, 
escalation may occur. No automated processing of email bounces may be carried out, 
however, a facility may be provided whereby the submitter of the job can manually 
indicate that particular emails were not successfully sent (via the web interface). 
20 If the SMS number could not be contacted (is invalid), escalation may occur. This is 

dependent on whether or not this level of reporting can be provided by the mobile service 
provider. 

If the surface mail address cannot be successfully barcoded, escalation may occur. The 
25 inability to barcode a mail address can be for a variety of reasons - for example there 
may be no postcode or an invalid postcode, or an invalid street number for a particular 
street. 

The following fields are available on the user configuration screen to store the following 
30 user preferences in relation to escalation: 
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• Escalate Email if no record of opening? 

• If yes to above, what is number of days email needs to be unopened before 
escalating? 

• Want ability to manually mark an email as requiring escalation via the Web 
5 Interface? 

• Want to Manually Intervene before any escalations actually occur? 



For originators that have 'Escalation' configured, all jobs submitted via the web interface 
automatically have escalation switched on. Escalation proceeds according to either the 
1 0 broadcast preference chosen, or if List preference is chosen as the broadcast preference, 
then escalation proceeds according to the list preference of the individual recipients. 

For originators that have escalation configured, an additional option is available via the 
FTP interface in the JobDescriptor.XML file. This is the 'Escalation' flag. If the 
1 5 'Escalation' flag is set to "Y", then escalation applies for this Job. Escalation proceeds 
according to either the broadcast preference chosen, or if List preference is chosen as the 
broadcast preference, escalation proceeds according to the list preference of the 
individual recipients. 

20 The Job Processing engine tracks the delivery status of each recipient and moves 

recipients along the escalation path when an escalation event occurs for that recipient 
(e.g. receipt of a bad fax report, or non-opening of an email within X days, or manual 
flagging by user that a particular job requires escalation). 

25 Manual flagging of escalation for emails may be set via the web interface. After 
submitting a Job, an originator is able to search for the Job, and then select an 'Add 
Email Escalations' button. This provides the originator with a list of all email recipients, 
and the originator is able to check an 'escalate' box next to any recipients that the 
originator would like escalated. The purpose of this screen is primarily to cater for the 

30 situation where the originator has received an email bounce and so would like to 

manually indicate that escalation is required. This facility also caters for other situations 
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where the originator/sender has some other prior knowledge that the recipient will not 
receive the email (for example - emailing to the accounts dept, but know that the regular 
email contact is on holidays and so want to send a fax/letter so that their stand-in receives 
the fax/letter). 

5 

Escalation Status: After submitting a Job, a user can at any time search for a Job and 
then view the current status of all of the recipients and whether the recipients have 
escalated or are awaiting originator approval to proceed with escalation. The reason for 
the escalation is also be shown (e.g. "fax failed after 3 retries", "Email unopened within 5 
1 0 days", "Street number invalid for street address", "manually flagged for escalation", 
etc.). 

Escalation Processing: From the Escalation Status screen, if the originator has 'manual 
intervention* configured in their profile, the originator is able to select a 'Process 
15 Escalations' function. This displays the list of recipients awaiting escalation. For any 
recipient that has had an escalation event occur, there is a 'proceed' checkbox next to the 
line for that recipient's status. The originator is able to tick some or all (via a 'tick all' 
button) of the recipients that originator would like the escalation to proceed for and then 
press a 'Proceed with Selected Escalations' button. 

20 

Message Retry: From the Escalation Status screen, the originator is also able to select a 
'Retry Messages' function, which displays a list of recipients awaiting escalation. 
Instead of escalating, the originator is able to select either 'Retry* or 'Retry with 
Modified Address' against a particular recipient If 'Retry with Modified Address' was 

25 selected, the user is first shown a screen to prompt them for the modified fax number, 
email address or surface mail address. For both options the application then proceeds to 
attempt a re-send to that recipient using the old or updated details. The user can carry out 
this procedure (one at a time) for each recipient they want to resend to. If the resend 
attempt succeeds, the is will no longer in the escalation state. If the resend attempt fails, 

30 the recipient reverts back to the awaiting escalation state. Whenever a 'Retry with 
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Modified Address' is selected, the originator is also emailed a copy of the original and 
modified details to remind the originator to update their own database. 

When an Escalation event occurs for a set of recipients (either due to the receipt of a Fax 
5 status report that shows failures, or alternately the timing out of the 'opened by' period 
that is used to indicate an email requires escalating), an email is sent to the originator that 
submitted the job. The originator can then go to the Escalation Status screen on the web 
to proceed manually with the escalations if the originator has the 'Manual Intervention' 
option configured. 

10 

X. Reporting Component 

The reporting component is responsible for receiving the delivery reports from the carrier 
interfaces, and combining the delivery reports together into one common status format 
for storage into a relational database. The reporting component also comprises of 
15 graphical interfaces and tools for use by originators to generate and view integrated 
delivery reports (either viewing them via a Web Based HTML interface, or receiving 
them via Email). 

Fig. 7 is a flow diagram illustrating the process 700 of how the different carrier reports 
20 are parsed and stored in a database to enable a web site to present integrated reports to an 
originator. Instep 710, processing commences by submitting a messaging job. Instep 
712, recipient information is stored in the database of recipient data 714. In step 716, 
messages are sent to the carrier via FTP. In step 7 1 8, the report is received from the 
carrier via FTP. In step 720, the carrier report is parsed and the recipient transmission 
25 results are stored in the database. Transmission ends in step 722. From step 720, the 
status is updated in the recipient database. 

In a separate but related process, the user originator may request the status report in step 
726. The updated status information in the recipient database is provided to step 728, 
30 which follows from step 726. 
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XI. Concurrencv/Pinelininf? of Merge/Transmission 

The hosted service is designed in such a way that sub-tasks that make up the merge and 
delivery process are run concurrently, where possible. This design enables a high level 

5 of throughput within the hosted service and also enables the hosted service to provide the 
complex escalation procedures that the hosted service supports. Fig. 9 shows how 
multiple instances 900 of the different components 902, 904, 906 operate concurrently to 
streamline the throughput of Ihe data. In particular, multiple instances of the merger 
module 902 operate concurrently and provide output to respective ones of multiple 

1 0 concurrent transmitter modules 904. The transmitter modules 904 are in turn coupled to 
respective ones of the multiple carriers 906. 

B. SECOND EMBODIMENT 
L Overview 

1 5 Embodiments of the invention provide a method, a system, and a computer program 
product (Web Service) for bulk communication of information to a single set of 
recipients via multiple delivery media (Fax, Email, SMS, Surface Mail and Archive) 
based on the recipients' delivery preferences and incorporating escalation to different 
media according to the recipients' preferences in the event of delivery failure. Computer 

20 software has been developed in an object oriented manner such that it is made up of 

multiple sub-components- The user interface to the software is preferably delivered as a 
web service. 

The message broad service utilizes the following techniques: 
25 (A) The system recognizes the common elements required in communication with 
customers and encapsulates those elements in an XML Document. These elements 
include a customer's delivery preferences and a set of redirection criteria. The delivery 
preferences and redirection criteria are specified using a unique shorthand notation. A 
proprietary XML schema has also been defined to describe the XML document format. 
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(B) The system provides a remotely accessible and secure electronic interface. The one 
single data stream supports all forms of messaging in a consistent manner. The data 
stream can be supplied via an interactive Web user interface or by non-interactive bulk 
submission through the Internet (by means of the FTP or other protocols). 
5 (C) The system supports a mechanism for specifying a Data Converter. The system has 
special code built in that enables customized Data Converters to be written and plugged 
in dynamically. The Data Converters take the recipient data in any format (i.e. as 
extracted from an organisation's accounting or ERP systems) and converts the data into a 
common XML format for feeding into the messaging engine. 

10 (D) The system provides data merging (personalization) capabilities enabling the system 
to merge recipient data into a variety of document formats, including PDF, HTML, TIFF, 
Microsoft Word and Text. The system uses an XSL-FO formatting engine to carry out 
the data merging. The personalization capability includes the ability to personalize the 
subject line and body text of email messages as well as messages being sent via SMS. 

1 5 (E) The System manages all of the following carrier interfaces: SMS, Email, Fax, 
Conventional (Surface) Mail and Archiving. This is done by having a separate code 
layer in the system that presents a common carrier interface to the rest of the messaging 
engine. This also enables future media types to be easily incorporated into the Systran 
(e.g. WAP). 

20 (F) The System provides a single, integrated reporting interface to the user by taking the 
different types of reports that are received back from the carriers and converting the 
reports into a common format for storage in a relational database. The system then 
reconciles these delivery reports against the individual messaging recipients in order to 
track delivery and drive the escalation procedures. This enables the system to provide 

25 reports to the user on the success and failure of individual messages and show the 
redirection path that has been taken for individual recipients. 
(G) The System has been implemented in a manner that enables a high volume of 
messaging throughput. It does this by breaking out the steps in the messaging process 
into different components. These components are then executed concurrently, so that 

30 many different steps are being executed simultaneously. 
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• (A) Delivery Preferences can be specified for individual recipients, as well as 
redirection Rules. For example, a recipient can specify that the recipient prefers 
to receive communications via Fax, but to send by Surface Mail if the Fax fails. 

• (B) There is one data stream by means of which recipient information is supplied 
5 to the system. Via this one stream delivery can be carried out via any of Fax, 

Email, SMS, Surface Mail and Archiving. 

• (C) The recipient list can be in any format and the system converts the list to 
XML. 

• (D) Merging (personalization) can be carried out using fields within the recipient 
10 list for all of the different delivery media (including personalization of SMS text 

messages, email body and subject text as well as Document merge for Word, 
PDF, HTML and MHTML). 

• (E) The system manages all interfaces to carriers (including surface mail mailing 
houses and to a hosted Archiving service). There is no need to install or manage 

1 5 any software at the originator. 

• (F) The one single recipient list can be used for delivery to all of the different 
target media. 

• (G) Integrated Reporting of delivery results, including reporting on escalations 
that have occurred and success/failure for all recipients across different media 

20 types. 

• (H) The system has been deliberately designed for the 'bulk mailing' scenario 
where a large number of recipients are being targeted, in an analogous manner to 
the way in which large numbers of recipients are targeted by conventional surface 
mail mailing houses today. 

25 • Allows Companies and Organisations to carry out bulk communication with their 

clients using the one system, via one interface and using a single recipient list but 
delivering via all currently available media including Conventional (Surface) 
Mail, Email (encrypted and non-encrypted), Fax and SMS, as well as delivery of 
documents to a hosted Document Archiving and Retrieval system. 
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• It also supports the specification of delivery preferences and redirection rules at 
an individual recipient level as well as at an overall level. 

• The system manages the interfaces to Fax, Email and SMS carriers and 
Conventional (Surface) Mail mailing houses. 

5 • The system also supports a variety of input recipient file formats and carries out 

data conversion to XML format 

• The system supports document merging using state of the art XML document 
formats and XSL and XSL-FO style sheets for data formatting and presentation. 

• The system has been implemented in a manner that enables a high volume of 
1 0 message throughput. 

• The system provides an integrated reporting interface that enables a user to view 
the messaging and escalation status of individual recipients. 



The technology can be provided as either a hosted service, commonly known as the 
1 5 Application Service Provider model, or in the form of a fully licensed model. There 
are three different ways to access the system and these three different access methods 
are supported by two different interface components. The two external interface 
components all utilise the same underlying common interface component. Fig. 29 is 
a block diagram depicting a system 3000 comprising a bulk interface 3010, a web 
20 interface 3012, and a common interface 3020. 

A. Web Graphical User interface (Browser/HTML based) 3012 

For entities that wish to submit jobs manually via a graphical user interface, a web 
browser based HTML interface 3012 is provided to the system. 

25 

B. Bulk interface 3010 

Bulk submission of jobs across the Internet is supported. This allows customers* 
ERP systems to send jobs directly to the system. FTP (File Transfer Protocol) is a 
common protocol for transferring files over the Internet The service provides an 
3 0 FTP interface as the bulk interface 3010 because this interface is a commonly 
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understood interface that is easy for entities to access. Other submission interfaces 
such as the formal interface described by the Universal Description, Discovery and 
Integration (UDDI) and Web Services Definition Language (WSDL) standards may 
also be used. 

5 

C. Common Interface 3020 

All of the various interfaces 3010, 3012 are lightweight, and marshal data into a 
common format for submission to an underlying common interface 3020 as shown in 
Fig. 29. The interface parameters are passed as XML. 

10 

The reporting component is responsible for receiving the delivery reports from the 
carrier interfaces, and combining the reports together into one common status format 
for storage into a relational database. This component also comprises of screens and 
tools for use by users to generate and view integrated delivery reports (either viewing 
15 them via a Web Based HTML interface, or receiving them via Email). The diagram 
in Fig. 7 shows how the different carrier reports are parsed and stored in the database 
to enable the web site to present integrated reports to the user. 

In order to provide a mechanism to enable a single recipient list to be used for 
20 merging (personalization) and delivery of data to a variety of different media, based 
on the recipients delivery preferences, a special XML schema has been defined. The 
Recipient List XML Schema is shown in Fig. 30. 

The key differentiating points are as follows: 
25 • The message distribution system is a general-purpose product for broadcasting 
messages to hundreds or thousands of recipients. 

• Data can be submitted in any electronic format to the message distribution 
system, including but not limited to printstream via numerous interfaces. 

• The messages can be personalised extensively for each recipient. 

30 • XML technology is used to define sophisticated message templates which support 
powerful merge facilities. 
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• The message distribution system incorporates a powerful feature known as data 
converters or Java Mapping Classes. This allows the message distribution system 
to accept recipient information in any format. 

• Messages can be sent to fax, e-maik paper or SMS currently. New media types 
5 (e.g., PDAs) can be added easily. Design of an output media type of 'archive' 

(which allows outgoing messages to be copied to an archive) is underway. 

• Each recipient can specify a different media type. Thus a single message 
distribution can be sent to some recipients by paper, others by e-mail, others by 
fax, etc. 

10 • A 'redirection* feature is provided. If a message cannot be delivered to a 
recipient's first choice media, the message distribution system retries to a 
specified second choice and even third choice. Thus, for example, if transmission 
to fax fails for a particular recipient, the message distribution system 
automatically tries to send by e-mail, paper or whatever. Redirection rules are 

1 5 specified individually for each recipient or globally for a whole job as necessary. 



In the second embodiment of the invention, an electronic message broadcasting system 
1 1 00 is disclosed as shown in Fig. 1 1 . The message distribution system 1 100 is designed 
specifically to handle a 'one to many' situation, where a single message 11 10 is received 
20 by the message distribution system 1 1 00 (and in particular by a system engine 1 120) and 
broadcast to dozens, hundreds or thousands of destinations 1 130. The message 
distribution system provides facilities for the message to be 'tailored' individually for 
each recipient Messages are received and transmitted via the Internet or by dedicated 
communications links. 

25 

Messages can comprise text, graphics, embedded audio/video, in fact, virtually anything 
that can be represented electronically. 

The message distribution system can be used to broadcast a wide range of information 
30 ranging from memos and marketing materials to invoices and statements. 
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Fig. 12 is a block diagram showing the overall architecture of the system engine 1 120 of 
Fig. 1 1 in greater detail. An Internet interface 1210 is coupled to an applications servo: 
1220, which in turn is coupled to a database server 1240. The application 1220 may be 
implemented using PC hardware 1232, for example, using the Microsoft Windows 2000 
5 operating system. 

The application server 1220 comprises a Java Virtual Machine 1228, JDBC 1230, the 
Apache Tomcat web server 1224, and JBoss application server 1226, The application 
server 1220 also comprises the application software 1222 including Java programs and 
10 utilities. 

The database server 1240 comprises an operating system level (e.g. Microsoft Windows 
2000) on PC hardware 1246, JDataConnect 1244, and SQL Server 1242. 

15 The system preferably runs on computers located in a secure data centre. It is intended 
that other message distribution systems are installed in data centres in other places. The 
system software 1220 is preferably written in the Java programming language and may 
include a number of third party utility packages (most of which are also designed for the 
Java platform). The message distribution system uses XML standards for representing 

20 data. 

The message distribution system can be run on a wide range of platforms, e.g. the system 
can be run on PC 'application servers' 1232, 1246 utilising Microsoft's Windows 2000 
operating system. The Java program environment is provided by the Apache Tomcat 
25 web server 1224 and the JBoss application server 1224. 

All persistent data is kept in a message distribution system database in another PC 
'database server' 1240, which is accessed via the Java JDBC interface 1230. The 
database software may be Microsoft's SQL Server 1242 which utilises JDataConnect 
30 software 1244 to handle the link to the message distribution system server. 
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1. Concepts 

The message distribution system is preferably implemented as a software suite developed 
specifically for the mass messaging market. The system controls the messaging 
computers known as message distribution System Engines, 

5 

The message distribution system accepts a message (i.e., an electronic representation of 
text, graphics, sound/video files, etc.) from a sender and distributes a copy of that 
message to a number (a few dozen, a few hundreds or many thousands) of recipients. 
Typically the sender is an organisation of some sort and the recipients are individuals or 

10 other organisations. The sender may be a customer and be identified by a customer id. 
The terms * sender' and * customer* are used interchangeably in this document depending 
upon the context. The content of the message may be tailored specifically for each 
recipient, but the overall format of the message is typically similar for all recipients. As 
an example, suppose the sender is a bank and the message represents a monthly bank 

1 5 statement. The overall format of the message (i.e., the name of the bank, the bank's logo, 
the column headings, etc.) is the same for all recipients but the details (i.e., the recipient's 
name and address, the account balance and the individual credit/debit transactions) are 
different for each recipient. 

20 The whole process of accepting a message from a sender and distributing multiple copies 
of the message to recipients is referred to as a job. When a job is complete, the message 
distribution system automatically prepares a job status report for the sender. This report 
summarises the outcome of the job (i.e., how many recipient messages were delivered 
successfully and how many failed) and provides details of success/failure on an 

25 individual recipient basis (e.g., how many times delivery to a particular recipient was 
tried and why it failed). 

The message distribution system also prepares a set of billing records containing more 
detailed information about the outcome of each recipient message transmission. The 
30 billing records are sent to a Billing System, where the billing records may be used at the 
end of the month for invoicing the customer. 
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Each customer is allocated one or more message distribution system accounts (each 
identified by an account id). Every job must be associated with an account. The account 
defines certain operational characteristics of the job (such as the maximum size of a fax 
5 page, the quality of printing required, the message distribution system features which can 
be used, etc.) and is used in the billing process to determine how much to charge the 
customer for the job. A customer might typically assign groups of appropriately 
configured accounts to his organisational units (cost centres, departments or whatever) 
within his enterprise. 

10 

A sender normally interacts with the message distribution system (i.e., submits jobs, 
retrieves job status reports, etc.) by means of an online web interface. The customer 
nominates certain individuals within his organisation to do this; these individuals are 
known as users (and are identified by a user id which is unique within customer). Users 
1 5 access the web interface by means of a web browser such as Internet Explorer or 
Netscape. 

In some cases, as an alternative to the web interface, it is possible for a user to submit a 
job using FTP file transfer across the Internet to the message distribution system. This 
20 option is discussed later in this document. 

A recipient can receive his message via a number of different media delivered by various 
carriers. The media include the following: 

• E-mail — The message distribution system sends the message electronically to a 
25 carrier who delivers the message as an e-mail to the recipient's e-mail address, 

either embedded within the e-mail body and/or as an attachment. 

• Paper - The message distribution system sends the message electronically to a 
carrier who prints the message, places the printed message in an envelope and 
mails the message to the recipient through the postal system. 

30 • SMS - The message distribution system sends the message electronically to a 
carrier who delivers the message as text to the recipient's mobile telephone. 
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• Fax - The message distribution system sends the message electronically to a 
carrier who forwards it to the recipient's facsimile machine. 

It is anticipated that other media will be introduced in the future. The system architecture 
5 is designed to support introduction of new media with minimal development effort. An 
'archive* medium to allow outgoing messages to be sent to an archive file may be 
implemented. 

All the media listed above are uniquely addressable. This address is referred to as a 
10 destination id. 

The format of the destination id is different for each medium type. For fax machines and 
mobile telephones, the destination id is a telephone number, for paper the destination id 
is a postal address, and for e-mails the destination id is an e-mail address. Thus a 
1 5 particular recipient might have the following destination ids, for example: 

• Fax destination id +61 2 1234 5678 

• SMS destination id +61 438 987654 

• Paper destination id Mr P Jones, 24 Waratah St, St Leonards, NSW, 2065 
20 • E-mail destination id piones(5lbigpond.com.au 

One destination id per medium type is used. Destinations are specified on a 'per 
recipient' basis; in any particular job each recipient can specify different media and 
different destinations. 

25 

To initiate a job, a user submits template files and recipient files to the message 
distribution system. A job may require one or more template files. A template file 
contains just a single template. A job requires one or more templates for each delivery 
medium. For example, a job that handles SMS and e-mail might require one template for 
30 the SMS messages and five templates for the e-mail messages (one for the e-mail subject, 
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one for the textual version of the e-mail body, one for the HTML version of the e-mail 
body and one for each of the two e-mail attachments). 

, Templates are supplied in a number of different formats including Adobe Acrobat PDF 
5 (PDF) format, TIFF image (TIF) format, Postscript (PRN) format, XML stylesheet 
(XSL) format, Microsoft Word (DOC) format and simple text (TXT) format 

Each template describes the invariant portions of the message (i.e., those portions which 
are identical for all recipients). 

10 

Certain types of templates (i.e., DOC, XSL and TXT only) are 'personalisable* (i.e., they 
may optionally contain one or more 'merge fields*). Also XSL templates may be 
accompanied by 'template artifact files*. 

1 5 • Merge fields are named 'place holders* within the template. Each merge field 
indicates a place where recipient-specific data are to be inserted at the time that 
the message distribution system creates a message for a particular recipient 
Thus, for example, a template might contain merge fields called 'cust_name' 
* account_balance' and 'date', which might appear within the template 1300 as 

20 shown in Fig. 13. 

• For illustration purposes, the example in Fig. 13 shows the merge fields delimited 
by 'chevron 9 characters. This is how they actually appear within DOC and TXT 
templates (but not within XSL templates). 

25 

• Template artifact files may accompany XSL template files. These comprise 
graphics, sound, video clips or other multimedia files. For example, if a bank 
statement message contains a logo, the template file may be accompanied by an 
image file (called 'BankLogo.jpg' perhaps) which contains the appropriate 

30 graphic. 
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A job requires one or more recipient files. When the recipient files are received, the 
message distribution system concatenates or otherwise combines the recipient files all 
together into a single file. The contents of this file are known as the recipient list. 

5 The recipient list comprises many recipient records (typically hundreds or thousands). 
Each recipient record may contain text that describes one intended recipient of the 
message. A recipient record may comprise the following information: 

• Recipient information - The record contains some basic information about the 
10 recipient, such as his name and a reference code. 

• Destination ids - There is one destination id for each medium by which messages 
can be delivered to this recipient. Thus, for example, if a recipient may receive 
messages by e-mail or fax only, the recipient record contains an e-mail address 

1 5 and a fax telephone number only; the destination ids for 'paper* and 'SMS' are 

null (indicating that the recipient cannot be contacted by mail or SMS). The fact 
that a destination id is specified does not necessarily mean that the id is used. The 
destination ids to be used to deliver a particular message are specified in the 
'destination preference information*. 

20 

• Merge values - A recipient record contains 'merge values' corresponding to the 
'merge fields' in the template files. The merge values are placed in the merge 
fields by message distribution system when the system generates messages for 
this recipient For example, a template might contain a merge field called 

< 25 *«account_balance»' and a particular recipient record might contain a merge 

value of '$45 1 .34' . When the message is delivered to the recipient, the text 
'$451 .34' appears in the message instead of the merge field name. 

• Destination preference information - The destination preference information tells 
30 the message distribution system which destinations to send the message to. 
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• For each recipient, up to a specified number (e.g., 3) of delivery attempts can be 
specified as part of the destination preference information. Each attempt can 
specify up to the specified number, (e.g., 3) of transmissions to different 
destination ids; the first of these is the master transmission and the others are 
5 copy transmissions. 



• The message distribution system commences with the first attempt The system 
sends the master and copy transmissions simultaneously. If the master 
transmission fails to reach the recipient, the message distribution system tries the 
10 next attempt. Processing continues in this way until either the master 

transmission has been successfully completed or until all attempts are exhausted. 



• Making multiple attempts to deliver master transmissions in this way is known as 
redirection. Any failure of a 'copy' transmission is not regarded as critical by the 

1 5 message distribution system and does not result in redirection. 

• The foregoing is illustrated by an example in Fig. 14. A recipient record 1400 
specifies the attempts and transmissions shown in Fig. 14. The message 
distribution system initially sends the master transmission to fax and 

20 simultaneously sends a copy to e-mail. If the master transmission (Le., fax) is 

successful, processing of this recipient is completed. 



If the master transmission is unsuccessful (e.g., if the fax number is engaged or 
unobtainable), the message distribution system initiates attempt number 2 (Le., the 
25 system tries to send the master transmission to paper and a copy to SMS). This 
marks the end of the message distribution system's processing because a third 
attempt is not specified. 
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II The Web Interface 

Interaction between users and the message distribution system may occur by means of a 
web browser interface. To commence interacting with the message distribution system, a 
user simply starts a web browser (e.g., Microsoft's Internet Explorer or Netscape's 
5 Navigator) and enters the appropriate URL. 

Entering the URL establishes a logical link between the user and the message distribution 
System Engine and causes the 'logon screen' 1600 shown in Fig. 16 to be displayed. 

10 The following description sets forth the screens to be displayed by the message 
distribution system and how they are used. 

Customers, Users and Accounts 

The web interface allows 'users' (representing 'customers' and operating under the 
message distribution system 'accounts') to submit jobs to the message distribution 
1 5 system and perform other operations. 

Within the organisation of a system operator, there may be a group of staff who are 
responsible for operational control of the message distribution system and for supporting 
the message distribution system's customers. They are referred to here as the message 
20 distribution system Support Team. The Support Team has overall administrative 

responsibility for the system and, in particular, has the job of setting up new customers to 
use the system. 

When a member of the message distribution system Support Team introduces a new 
25 customer to the system, the Team member creates the following items in the message 
distribution system database: 

• a single 'CUSTOMER' record containing information about the customer, 

• several 'ACCOUNT' records each containing information about an account that 
this customer can use, and 
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• one or more 'USER' records describing a administrator users (i.e., users with 
special privileges). 

• A customer's administrator users may be allowed to create one or more standard 
5 users for this customer (i.e., users without administrator privileges) so the 

administration of the standard users is under the customer's direct control. 
However, administrator users may only be created by the message distribution 
system Support Team. 

10 The message distribution system maintains information relating to a particular customer. 
This information may comprise the customer's account information, user information, 
and information about the various jobs submitted by that customer's users. This 
information may comprise and normally forms a 'closed group' from an access control 
point of view. A customer's users can only access information about accounts, users and 

1 5 jobs related to that customer. The users cannot access information about other 
customers. This is a security requirement of the message distribution system. 

There may be one exception to this. The message distribution system Support Team may 
be registered within the message distribution system as a 'special customer* with a 
20 customer id of 'control'. Users belonging to this special customer ('control users*) may 
have special powers as befits the supervisory role performed by the message distribution 
system Support Team. In particular, for control users only: 

• administrator users may have authority to access and change customer, user and 
account information for any customer, and to submit jobs for any customer, and 

25 • standard users may have the ability to view (but not change) customer, user and 
account information for any customer, and to submit jobs and report e-mail errors 
for any customer. 

Control users may 'impersonate' a user of any nominated customer and thereby access 
30 the system as if the control users were representing that customer. When a customer is 
'impersonated' by a control user in this way, it is known as a proxy customer. 
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The rules governing the web interface functions which various types of users are allowed 
to perform are summarised in the table 1 500 in Fig. 15. Descriptions of the functions 
shown in Fig. 15 are provided hereinafter. 

5 

The functions denoted with footnote "1" of Fig. 15 are customer-specific. They are 
performed for the nominated proxy customer (i.e., the control user first nominates a 
particular proxy customer and then performs the function). Other control customer 
functions do not require nomination of a proxy customer first In relation to footnote "2" 
1 0 in Fig. 15, users may also be allowed to alter certain fields on their own USER record, 
but not on other users 7 USER records. 

Logging On 

A logon screen 1600 that may be used is displayed in Fig. 16. The user may be required 
to enter a customer id, a user id and a password on the logon screen 1600. 

15 

The Screen Layout 

Once a user has successfully logged on, a main screen 1700 in Fig. 17 is displayed and 
remains displayed until the user 'cancels' out of the screen. The main screen takes the 
form of a main menu on the left and, in some cases, a series of tabs across the top. 
20 Fig. 17 shows the scheme. 

The left hand side is occupied by the main menu ('Main menu 1 \ 'Main menu 2\ etc.). 
The currently selected main menu option may be highlighted by enclosing the option in a 
black border ('Main menu T in Fig, 17). 

25 

The top of the screen may contain the customer name (followed by a customer id in 
brackets) and the user name (followed by the user id in brackets). The user name and id 
identify the user who is currently logged on. The customer name and id may denote the 
customer who 'owns' the user or, if the customer is 'control 1 , the proxy customer. Proxy 
30 customers and administrator users may be displayed in italics. 
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The remainder of the screen comprises a panel or a panel group (i.e., one or more panels 
conceptually stacked on top of each other) corresponding to the currently selected main 
menu item. In the case of a panel group, tabs at the top of the screen may be used to 
5 display (i.e., bring to the top of the stack) the individual panels within the group. Each 
panel contains information comprising descriptive text, data entry fields, drop-down lists, 
radio buttons, checkboxes and other artifacts. Buttons to submit or cancel the panel or to 
invoke help information may be situated at the bottom. 

10 Administration 

An administration panel group allows a customer's USER and ACCOUNT records to be 
viewed and, in some cases, altered. 

An example of a panel for viewing a user is shown in Fig. 1 8. There may be several 
15 variants of this panel, one for normal users, one for the customer's (or control) 

. administrator user and one for the specific user represented by this USER record. Fig. 1 8 
shows the panel 1800, which would be seen by an administrator user. 

The control administrator users and the customer's administrator users can enter 
20 information into any of the fields on this panel For most standard users, all fields are 
'read only'. For the standard user to which this record applies, all fields except the 
•password', 'contact' and 'test destination' fields are 'read only'. 

Most of the fields have a 'one to one' correspondence to the fields in die USER record on 
25 the database. The ticked items in the list of 'accounts for which this user may submit 
jobs' reflect the 'USER_j\CCOUNT_XREF' records for this user. 

Submitting a Message Distribution System Job 

A user may submit a job to the message distribution system using one of two interfaces. 
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• Enterprise Interface 

The enterprise interface is typically used by large enterprises that possess 
sophisticated computer systems to track and manage their customers and 
suppliers. The enterprise interface is oriented towards 'essential mail', such as 
5 invoices and statements. 



• In such cases the message formats tend to be complex (incorporating logos and 
other graphics) and do not change frequently. This means that development of 
appropriate templates is a time consuming task but, once completed, does not 
1 0 need to be repeated often. 



• The templates for an enterprise interface customer may be developed by the 
message distribution system Support Team to the customer's specifications. The 
completed templates may then be stored within the message distribution system's 
1 5 database under a company * s control. Whenever the customer runs a job, the 

system references the templates (by quoting the appropriate job type), but the 
templates themselves do not change and, indeed, cannot be modified by the 
customer. 



20 • Customers using the enterprise interface may have a database (on their own 
computer system) containing contact details and other information about their 
suppliers, customers, staff, associates, etc. So, when the customers wish to send 
messages to various recipients via the message distribution system, the customers 
may run a 'database extract 7 program against their own database to generate the 

25 recipient file. 

• Enterprise interface templates may be stored in XML Stylesheet (XSL) format. 
An exception to this may be the case of e-mail attachments that do not contain 
merge fields. They may be specified in Adobe Acrobat PDF format. 

30 
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• Recipient file formats vary widely but the message distribution system converts 
the file formats all to XML format on receipt 

• As an example of an application using the enterprise interface, consider a monthly 
5 bank statement job. The overall format of the statement (i.e., headings, logos, 

boilerplate text, etc.) is not regularly changed by the bank, if ever. This format 
may be described by a set of XSL template files developed by the message 
distribution system Support Team to the bank's specifications. However, the 
statement details (customer name, address, transaction details, account balance, 
1 0 etc.) are different for each customer each month. Typically, the statement details 

are extracted by a program from the bank's mainframe database and then 
forwarded as a recipient file to the message distribution system each month. 

• Standard Interface 

1 5 The standard interface may be used for smaller, less complex jobs. 

• A user of the standard interface may be responsible for preparing the user's own 
template files and supplying the template files whenever the user initiates a job. 
This may be practical in situations where the template is relatively simple 

20 (e.g., memos, press releases and marketing campaigns that can be prepared using 

a simple word processor). In such situations, it is common for new template files 
to be prepared for each the message distribution system job. 

• In some cases (i.e., where simple textual information is involved), the user can 
25 enter the user's template file online via the standard interface. In other cases, the 

user may prepare a template file offline (e.g., in Microsoft Word 'DOC format). 

• Recipient files may be in 'comma separated values' (CSV) format, but may be 
converted to XML format by the message distribution system upon receipt. 

30 
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The standard interface is well suited to a customer who wishes to quickly generate simple 
memos or marketing materials and broadcast those messages to its customers. The 
enterprise interface is suited for stable applications, such as statements and invoices, 
where the format endures over a period of time, but is used repeatedly during that time. 

5 

Tables 3 and 4 summarise the differences between the two interfaces in technical terms. 

TABLE 3 



10 Features 



Enterprise Interface 


Standard Interface 


Templates and associated images are 
predefined and stored in the message 
distribution system database 


Templates are submitted with each job 


Mergeable templates are in XML Stylesheet 
(XSL) format 


Mergeable templates are in Microsoft 
Word (DOC) or simple text (TXT) 
format 


Recipient files can be in any format (but are 
converted to XML by the message 
distribution system) 


Recipient files may be in CSV format 
(but are converted to XML by the 
message distribution system) 


May output to e-mail, fax, SMS or paper 


May output to e-mail, fax or SMS but 
not paper 



TABLE 4 

15 



Template Formats 



Type of Template 


Enterprise Interface 


Standard Interface 


Medium 


Usage 


Mergeable 


Non-mergeable 


Mergeable 


Non-mergeable 


Paper 


One or 
several pages 


XSL 








Fax 


Subject page 


XSL 




TXT 




One or 
several pages 


XSL 




DOC 


PDF, Postscript, 
TIFF 
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E-mail 


Subject line 


XSL 




TXT 






HTML body 


XSL 






HTML 




Text body 


XSL 






TXT 




Attachment 


XSL 


PDF 


DOC 


Any format 


SMS 


Message text 


XSL 




TXT 





The corresponding format of messages sent to carriers may vary: 
5 • Each paper message may be sent to the carrier as a postscript file 

• Each fax message may be sent to the carrier as one or more TIFF files (with the 
'subject' information included in a special header in plain text format) 

• Each e-mail message may be sent to the carrier in a composite format in which: 

- the subject line may be encoded in plain text form in a special control file, 
10 - the HTML and text body may be encoded as an HTML file and a plain text 

file respectively, 

- enterprise interface attachments may be sent as PDF files, and 

- standard interface attachments may be sent in the same format as originally 
received, 

15 

• One exception to the foregoing rule may be that any standard interface attachment 
in DOC format is sent to the carrier in PDF format. 

• HTML files handled by the standard interface are preferably completely self- 
20 contained (the files do not include references to external artifacts such as image 

files). 

• Each SMS message is sent in text form to a mobile phone. 

25 The user first selects the account under which this job is run. The 'drop-down' list may 
list the names of all of the customer's (or proxy customer's) accounts that the user is 
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authorised to use. When the user clicks 'Submit', a new panel is displayed to reflect 
either the enterprise or the standard interface (as specified in the selected account). 

The Enterprise Interface 

5 Fig. 1 9 shows the layout of the enterprise interface job submission screen 1900. 

• Job reference 

- The job reference field may be optional. The user may enter a name for the job 
which is meaningful to him. This name is displayed on all reports concerning this 

10 job. 

• Job type 

- This field offers the user a list of job types, each of which is identified by a name 
that is meaningful to the user. The user must select one hem from the list. 

- Job types are represented in the message distribution system database as job 

1 5 configurations. Each job configuration comprises job-level information and a 

collection of template files and template artifact files that have been pie-prepared 
by the message distribution system Support Team, tested and stored within the 
database. 

• Recipient files 

20 Initially, the user may be offered one text entry field (with associated 'Browse' 

and 'Upload' buttons). 

To specify a recipient file, the user clicks the 'Browse' button which causes a 
browse window to be displayed. After the user selects the required file, its 
25 filepath appears in the text entry field. When the user clicks the 'Upload' button, 

the file is uploaded to the message distribution system and appears in the 
'uploaded files' list. The user may upload as many files as the user wishes in this 
way. 
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The 'Remove' button alongside the 'uploaded files' list can be used to remove 
a selected uploaded file. 



The enterprise interface of the message distribution system accepts recipient 
files in a wide variety of formats. The recipient is converted to XML format 
and held in converted form database in this form. 



• Job start time 

The user may be offered the option of processing the job immediately or 
1 0 scheduling the job to start at a later date and time. The 'date' field offers a choice 

of up to 30 days in the future. The 'time' fields allow the user to specify the start 
time in hours and minutes. 



The user selects 'Submit' to submit the job. After the job is submitted, the message 
15 distribution system locates the templates, template artifacts, and other job information 
corresponding to the specified job type in its database. The system then validates the 
recipient files as necessary. If errors are encountered during this validation process, the 
message distribution system displays details of the recipients in error. The user then 
corrects the errors and resubmits the job. 

20 

Viewing Job Status Reports 

A user may request a job status report at any time after a job has been submitted. The 
message distribution system obtains the current status of the job from information on its 
database and displays an appropriate job status report on the screen (which the user may 
25 then print if the user wishes). 

The example in Fig. 20 shows a full job status report 2000 (i.e., including all four 
options) for an invoice distribution job submitted using the enterprise interface. The 
report 2000 may be displayed in a 'printer friendly' format (black on white) and may be 
30 displayed in a new browser window. In the example, the message distribution system job 
id is '34656' and the job reference assigned by the user is 4 Invoice3\ 
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The job was submitted at 22:21 under account 'Essential Mail' and the job status report 
was generated 4 hours and 3 1 minutes later (at 2:52am next morning), while the job was 
still in the 'second attempt' phase (as indicated by the 'job status'). The possible job 
5 statuses are 'Processing not started', 'Attempt 1 in progress', 'Attempt 2 in progress', 
'Attempt 3 in progress' and 'Complete' plus various error statuses. The job specified 
763 recipients and was submitted via the enterprise interface. 

The remainder of the report indicates the status of the message transmission at the time 
10 the report was generated. Information is divided into three categories: 

• 'Master message' information relates to the transmission that was specified first 
in the recipient record for each attempt. A failure in transmission of a master 
message potentially causes redirection to take place (i.e., initiates the next 
attempt). 

15 • 'Copy message 1 information relates to all other transmissions, which do not 
trigger redirection. 

• 'E-Mail attachments opened' only refers to the opening of e-mail attachments. 

In the example report 2000, 763 master messages were sent, one per recipient. 
20 Altogether, 1 2 of them failed and caused a second attempt. Of the 763 master messages, 
two failed (even after attempting any specified redirections). Another four are still 
outstanding (i.e., the four messages were sent but the delivery status has not been 
determined yet). Another 94 'copy' messages were sent. Of these, 89 were successfully 
delivered, two failed and three more are still outstanding. 



25 



The second and third sections of the report specify details of each individual 
transmission. Each transmission status is presented in the following format: 
nn-mmm-hh:mmd 

where: 



30 
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• 'nn' represents the status of the transmission as follows: 
'OK' indicates success. 
'IP' indicates 'in progress 5 . 

*NC indicates 'not confirmed' (i.e., assumed OK but not definitely 
5 confirmed as such). 'NC status is a peculiarity of e-mail, explained hereinafter. 

- 'two digits' indicate that an error occurred (and the digits indicate the 
reason for failure). 



• 'mmm' is the destination medium (EML, FAX, SMS or PAP), 

10 • 'hhrmm* is the time of delivery or non-delivery (or, for SMS and paper, the time 
of transmission to the carrier), 

• *d' is a superscript digit that is only included if the message was delivered (or 
failed to be delivered) on a subsequent day. The digit is * V for the next day, *2' 
for the second next day and so on. 

15 

In the 'master message' section, all recipients whose master message transmission foiled 
(even after several attempts) or is still 'in progress' are grouped at the front of the report. 
The others are sorted by recipient reference. In the 'copy message' section, recipients are 
sorted in the same sequence. The last section of the report indicates times when e-mail 
20 attachments were opened. Each attachment is identified by 'Xn 5 where V is a number 
which identifies the attachment in the legend at the beginning of the section. The 
foregoing report 2000 is merely an example, and numerous variations may be practiced 
without departing from the scope and spirit of the invention. 



25 Job Configuration (control users only) 

Hie job configuration panel 2100 of Figs. 21 A and 21 B is available to control users and 
is used to add, change and delete a cluster of records in the message distribution system 
database corresponding to a job configuration. Only the job configurations for enterprise 
interface jobs may be accessed. 

30 
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After selecting the c Job Configuration 1 main menu option, a selection panel is displayed 
offering the user a choice of selecting an existing job configuration or creating a new 
one. After completing this panel the main job configuration panel 2100 is displayed. 

5 The panel 2100 of Figs. 21 A and 21B shows full details of the specified job 

configuration. The information may be formatted as a number of sections divided by 
horizontal lines. Each section may represent one record in the job configuration record 
cluster. In the example shown, the job configuration comprise a 

JAVA_MAPPING J^LASS record, a JAVA_MAPPING_CLASS^RESOURCE record, a 
10 CONFIG_DATA record, a TEMPLATE record, and two TEMPLATE_ARTIFACT 
records. 

Each section shows the filename of the file that is imported into the record and the values 
of other fields in the record. The user may alter fields as necessary. The user may also 
15 . import new files (replacing the existing ones) by using the 'Browse* button (which may 
invoke a 'browse' window from which the user can select the file to import) followed by 
the 'Import' button. Alternatively, the user may use the 'Delete 1 button to delete the 
whole section (i.e., to delete the associated record). 

20 For sections which can repeat, an 'Add a new ... record 5 button is provided to add another 
empty section. 

The section at the bottom of the panel allows the files within the cluster to be exported as 
a ZIP archive to a nominated file. The file may be stored on the message distribution 
25 system server in a specified directory (e.g., c C:\JobConfigurations > ) and may have an 
automatically generated name that is a concatenation of the customer name, job 
configuration display name (i.e., job type) and date. Changes are not made to the 
database until the user clicks the 'Submit' button. The delete button allows the whole 
cluster to be deleted if necessary. 

30 
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IV. The FTP Interface 

In certain cases, customers may need to generate recipient files from their enterprise 
systems and send the files to the message distribution system for distribution 
automatically (i.e., without human intervention). In such situations, the web interface 
may not be appropriate to their needs. The message distribution system therefore allows 
'enterprise interface' style jobs to be submitted through the Internet by an FTP 
transmission. The FTP transmission replaces the job submission (and associated) 
screens. The customer, user and account records should be set up correctly before the 
FTP transmission. 

After an FTP job submission, a user may use the normal message distribution system 
facilities (ie., inspection of the Job Status Report) to monitor the progress of the job. 

To submit a job via the FTP interface, the user employs an FTP client program to send a 
single ZIP file to the message distribution system via the Internet. The transmission 
process may be performed using SSL security and require the user to enter an FTP 'user 
id' (which may take the form 'ccccc-uuuuu\ where 'ccccc' is the user's message 
distribution system customer id and 'uuuuu' is the user's message distribution system 
user id) and an FTP 'password' (which may be the same as the user's message 
distribution system user password). 

The ZIP file contains the following files: 

• a job control file called 'jobcontrol.xml'; and 

• one or more recipient files whose names are specified in the job control file (see 
Recipient Files) 

The format of the job control file (jobcontroLxml) 2200 is shown in Fig. 22. Most fields 
in the file are counterparts of their web interface equivalents. The test attribute 
specifies whether this is a test job or not. Customers may specify a unique 'job- 
reference* so that the customers can identify the job on the 'status report' screen later. 
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V. System Architecture 

The internal architecture of the message distribution system is described hereinafter, 
including a selection of the major processing flows through the message distribution 
5 system. An overall knowledge of J2EE and Java web container concepts is desirable, but 
not essential for understanding the following description. Occasionally this section 
makes reference to tables (or 'record types') in the database. The names of these are 
printed in upper case. Details of the function and structure of the records are contained in 
Section VII. 

10 

Fig. 23 is a block diagram illustrating the architecture of the message broadcasting 
system 2400. The system 2400 comprises a front end 2410 and a back end 2420. A user 
2402 can retrieve a job status report using module 2412, submit a job using the standard 
interface 2414, and submit a job using the enterprise interface 2416, all in the front end 
1 5 2410. An FTP file 2404 may be provided to the enterprise interface 2412. 

In the standard interface 2414, job information is received from the user 2402, and 
recipient lists and templates are uploaded. "Validate" is invoked to check recipient list 
The submit request is received from the user, and the "submit" process is invoked. 

20 

From interface 2414, the standard job submission processor 2424 of the back end 2420 
validates or checks the input data and submits the job. This involves converting the 
recipient list to XML and storing the job in the job queue. Processing then continues at 
flux module 2432. 

25 

The enterprise interface receives job information from the user 2402 and also uploads the 
recipient list. The recipient list is checked by invoking the validate process. The submit 
request is received from the user, and submit is invoked to process the request. From the 
interface 2416, processing continues at the enterprise job submission processor 2426. 
30 This validates the recipient list by checking the input data, and operates the submit 
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process, which converts the recipient list into XML and stores the job in a job queue. 
Processing then continues at flux 2432. The output of processors 2424 and 2426 is an 
event. Actions then occur from flux 2432. 

5 The action proceeds to the bundle processor 2450. The module 2452 builds one 

transmission bundle for each medium type, and then initiates a process bundles thread (a, 
b, c and d) for each transmission bundle. These threads are depicted A, B, C and D and 
are coupled respectively to modules 2454, 2456, 2458, and 2460. Each of these modules 
2454, 2456, 2458, and 2460 has a similar format For example, the fax transmission 

10 bundle 2454 involves merge, format and then transmit operations. The paper 
transmission bundle 2456, the SMS transmission bundle 2458, and the e-mail 
transmission bundle 2460 have similar arrangements. The output of each bundle module 
is provided to a respective carrier, for example, expedite 2462, EDI post 2464, SMS 
reach 2466, and message reach 2468, which are all carriers. Each carrier provides a 

1 5 status report back to the back end 2420. Expedite 2462 provides a fax status report 2442, 
EDI post 2464 provides a paper status report 2440, SMS reach 2466 provides an SMS 
status report 2438, and message reach 2468 provides an e-mail status report 2436. 

The e-mail status report 2436, the SMS status report 2438, the paper status report 2440, 
20 and the fax status report 2442 are provided to the status collector module 2434. This 
module 2434 is invoked periodically by Flux. 2432. It retrieves status information 
supplied by the carriers and applies it to the job queue. The job queue 2430 has job and 
template information, recipient information and status information. The job queue 2430 
can provide billing records to the billing system 2460 and update status information to 
25 the bundle processor 2450. The job queue 2430 provides output to the status report 

module 2422, which retrieves status information, as an XML document preferably. The 
status report module 2422 provides the job status report that is retrieved by the module 
2412 in the front end 2410. The user 2402 can retrieve the XML status report, formatted 
using XSL stylesheet and display it in a printer friendly format. These and other details 
30 are set forth in greater detail hereinafter. 
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The Job Queue 

The job queue 2430 is a main component of the message distribution system 2400, The 
queue 2430 contains details of every message distribution system job which is currently 
running, waiting to run or has recently completed. Each job is represented in the 
5 database by a cluster of records of various types. Each cluster is headed by a JOB 
record. The record contains details of the job itself, the templates that are used, the 
recipients to which messages are to be sent, the merge fields, and the destinations. 

During normal operation, the message distribution system 2400 scans the job queue 2430 
10 at predefined times (e.g. every minute) and extracts details of all jobs that are running or 
which have recently completed. Any message distribution system Support Team 
browsers that are displaying the 'console* panel access this data extract and use the data 
obtained to display the current status of jobs in the system. In this way, the message 
distribution system Support Team has an up-to-date overview of the job queue 2430. 

15 

The team makes use of the functions offered by the 'Job control' panels to influence the 
processing of a job (e.g., recover a faulty job, retransmit transmission bundle files, etc). 
Thus, the job queue provides a central point of control which can be used to smooth 
processing loads on the system 2400, react rapidly to customers* requests and fix 
20 unexpected problems without the need to resubmit users' jobs from scratch. 

A job is placed in the job queue 2430 as soon as the job has been validated and then 
submitted by the user via processor 2424, or 2426. The job remains in the queue 2430 
until the job has completed and for some time thereafter (to give the user time to inspect 
25 the job status report 2422 produced by the job). It may be removed by a 'garbage 
collection' process later. 

Processing a Job 

Again, Fig. 23 shows the high level architecture 2400 of the message distribution system. 
30 The large box 2400 denotes the message distribution system itself. Data structures are 
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modules 2434, 2436, 2438, 2440, 2442, 2454, 2456, 2458, and 2460 and external entities 
are modules 2402, 2404, 2460, 2462, 2464, 2466, and 2468. Processes are depicted by 
modules 2412, 2414, and 2416 (servlets and JSPs) and modules 2422, 2424, 2426, 2434, 
and 2450 (session beans). 

5 

The system 2400 is essentially split into two halves, the front end 2410 and the back end 
2420, and the job queue 2430 represents the 'bridge' between them: 

• The front end logic 2410 may be supplied by Java 4 JSPs' and 'servlets' running in 
the Tomcat container. 

10 • The back end 2420 may comprise Java EJB 'session beans* (which, in turn, make 
use of EJB 'entity beans' and other Java objects) running in the JBoss container. 
The front end does not access the database directly, but instead invokes session beans in 
the back end 2420 to do so. 

The Front End 

1 5 The message distribution system front end 24 10 contains the logic concerned with 

handling the user interface. The front end 2410 is designed to provide fast response to 
users 2402, so lengthy processing tasks may be excluded from the front end 2410. 

The front end's main function is to receive jobs submitted by users 2414, 2416 and to 
20 place them on the job queue 2430 to await processing. The diagram shows three of the 
more important front end processes 2412, 2414, 2416: 

• submitting a job via the enterprise interface 24 1 6, 

• submitting a job via the standard interface 2414, and 
25 • requesting a job status report 2412. 

There may be other front end processes but, for the sake of brevity, such processes are 
not included in Fig. 23. 
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Each 'front end' process (comprising a mixture of servlets and JSPs) has a corresponding 
'back end* session bean, which performs all its database retrievals and updates. This 
allows the front end 2410 to provide good interactive response by freeing the servlets and 
JSPs from database access/locking considerations. 

5 Flux 

Whenever the front end 2410 places a job on the job queue 2430, the 'front end' (or, to 
be more precise, the front end's session bean) triggers a Flux event 2432. Flux is an 
event scheduling tool supplied by SIMS Software. The scheduling tool runs continually, 
as an independent process within the Java virtual machine, whenever the message 

1 0 distribution system 2400 is active. The tool keeps its own tables of information within 
the message distribution system database. These are managed entirely by Flux 2432. 
Flux module 2432 responds to events triggered by timers or by other processes and takes 
predefined actions for each one. For example, when a new job is placed on the job queue 
2430, the front end's session bean defines an event to Flux 2432 to be triggered 

1 5 immediately (or at some future time if the user has scheduled a job to be run later). 

When the event is triggered, Flux 2432 invokes a session bean in the 'back end' 2430 to 
deal with the event. 



The Back End 

20 The 'back end' 2420 contains a set of session beans which act as 'helpers' to front end 
processes. The back end session beans perform the database access operations, which the 
front end components require. For example, 



• EnterpriseJobSubmissionProcessorBean. java performs database Operations 
25 for the servlets and JSPs that implement the enterprise job submission interface. 

• statusRepor tBean . j ava collects status report information from the database for 
use by the servlets and JSPs which implement the 4 Job status report* function 

• AccountBean . j ava performs database I/O on ACCOUNT records on behalf of 
the servlets and JSPs which implement the account maintenance panels. 
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The back end 2420 also contains the session beans which perform the 'real work* of the 
message distribution system 2400, namely the processing of jobs obtained from the job 
queue 2430. The processing of a job proceeds broadly as follows: 

5 

1 . The message distribution system 2400 scans all the RECIPIENT records in the 
job and, for each one, identifies the TRANSMISSION records linked to the first 
ATTEMPT record. Each one of these represents a destination to which a 
message must be sent as part of the first attempt. The message distribution 

10 system 2400 then generates several transmission bundles 2454, 2456, 2458, 2460 

(sometimes known as 'transmission packet bundles') in memory. There is one 
transmission bundle 2454, 2456, 2458, 2460 per destination medium (Le., one for 
fax, one for e-mail, etc,), each containing several transmission packets. Each 
transmission packet contains information about a recipient with a 'first attempt' 

1 5 destination directed to that medium. 

Thus, for example, if a particular RECIPIENT record specifies 'transmissions* to 
both fax and e-mail in its first 'attempt', a copy of that recipient's details appears 
in both the fax transmission bundle and the e-mail transmission bundle, 

20 

2, The transmission bundles are then processed in parallel on different 

processing threads. Each transmission bundle is processed in three phases: 
Merge phase - The merge values from the recipient records are 
substituted into the appropriate merge fields in the template(s) for that 
25 medium, thus creating a fully merged message for each recipient. 

Format phase - Each message in the bundle is reformatted, if necessary, 
into the appropriate output format (e.g., TIFF for fax). 

30 Transmit phase - Each transmission bundle is written to a disk file and 
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then transmitted to a carrier (e.g., Xpedite for fax, MessageReach for e- 
mail, EDI Post for paper, etc.) for onward transmission to its destination. 

3 . The message distribution system 2400 then waits for carrier status reports to be 
5 supplied by the carrier. Each carrier 2462, 2464, 2466, 2468 produces a carrier 

status report for each transmission bundle received. This report 2436, 2438, 
2440, 2442 indicates the result of each individual delivery of a message to a 
recipient. Retrieval of carrier status reports is known as status collection 2434. 

10 4. The message distribution system 2400 uses the information in the various carrier 
status reports 2436, 2438, 2440, 2442 to update the recipient status information in 
the job queue 2430 (held in the TRANSMISSION records). This information 
includes success/failure codes, time transmission completed, number of 
pages/bytes sent, etc, etc. 

15 

Once all the various carrier status reports for the first 'attempt* have been received and 
placed in the job queue 2430, the message distribution system 2400 scans the recipient 
data in the job queue 2430 again. If there are any recipients for which the master 
(i.e., first) transmission of the first attempt failed, those jobs are reprocessed by the 
20 message distribution system 2400 (by repeating steps 1 to 4 above) using their 'second 
attempt' transmissions. If the master transmissions of any of these second attempts fail, 
the process is repeated once more for the third attempt transmissions. 



At any time during or after the processing of a job, the customer may request a 
25 consolidated 'job status report*. This gives a complete summary of the job details, the 
number of recipients, and the fate of each message sent as at that instant in time. 
Optionally, the user can have this report automatically e-mailed to the user when the job 
completes. This option is indicated in the account record. The message distribution 
system may create a set of billing records (one for each attempted transmission to a 
30 recipient) containing full details of each transmission attempt (i.e., number of pages, 
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number of bytes sent, success/failure status, etc.) and sends them to the Billing System 
2460 where the records may be used to invoice customers. 

VI. Data File Structures 

5 The formats of several data files used by the message distribution system are described 
hereinafter. 

Template Files 

Template files can be supplied in a wide range of formats, which may be divided into two 
groups, namely those that can contain merge fields and those that cannot. 

10 

The first group may comprise XML Stylesheet (XSL) files, Microsoft Word (DOC) files 
and simple text (TXT) files. 

• XML Stylesheet (XSL) files 

- An XML Stylesheet is a file, expressed in XML notation, which describes 

1 5 precisely the format of a document (including text, images, margins, headers, footers 
and other artifacts). The file also contains provision for defining 'merge fields*. The 
process of scanning a recipient file (in XML format), extracting each recipient's 
'merge values', combining them with the XSL stylesheet, and producing the output 
document (in a format known as XSL:FO) for each recipient may be performed by a 

20 software product called Xalan (supplied by Apache). Details of XSL and XSL:FO 
can be found in the document: Extensible Stylesheet Language (XSL), Version 1.0, 
W3C Recommendation, 1 5 October 2001 , published by the World Wide Web 
Consortium and available at http://www.w3.org/TR/xsl . 

25 • Microsoft Word (DOC) files 

- DOC files may be produced by the Microsoft Word word-processor. 'Merge 
fields' can be defined in a document and replaced with 'merge values' using Word's 
standard 'merge' facilities. In the message distribution system, merging of DOC 
templates may be performed by Microsoft Word itself. Word runs as a stand-alone 

30 program executing directly under the control of Windows 2000 (i.e., outside the Java 
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Virtual Machine). The message distribution system may use Microsoft's DCOM 
facilities to interact with Word (i.e., to pass templates and recipient files to it and to 
receive the merged results). 



5 • Text files (TXT) 

- Text files are simple strings of ASCII text which may, optionally, contain merge 
fields. Where appropriate, 'end of line* characters (ie, <CR> and <LF>) are permitted 
but no other formatting characters are allowed. 

10 Other types of template, which cannot contain merge fields, include the following: 

• TIFF (TIF) Files 

TIFF files contain images in bitmapped graphics form. 



1 5 • Adobe Acrobat Document (PDF) Files 

The format of these files is published by Adobe. 

• Postscript (PRN) Files 

Postscript files are specifically designed to drive a wide range of printers (and 
20 may be used by the message distribution system to produce output destined for 

paper). A user normally produces a Postscript file by entering text and other 
information into a word processor and then outputting the file to a print file 
(which, by default, has a file type of PRN) rather than a physical printer* 

25 • HTML (HTM) Files 

HTML files comprise information formatted in the HTML markup language. 



Recipient Files 

Users of the enterprise interface 2416 submit files to the message distribution system 
30 2400 in a wide variety of formats, whereas users of the standard interface 2414 
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preferably submit them in 'comma separated values* (CSV) format A special Java class 
(part of the Data Converter) is used to convert the submitted files to XML format in 
module 2424 or 2426 before placing them in the job queue 2430 (in the message 
distribution system database). This class is held within the JAVA JVLAPPING_CLASS 
5 record within the job configuration held in the database. The java mapping class may 
make use of other artifacts to assist in the mapping process. This might include other 
Java classes, XFlat mapping files, and XSL stylesheets. These artifacts are kept in 
JAVA_MAPPING_CLASS_RESOURCE records within the job configuration held in 
the database. 

10 

An XFlat mapping file is a set of statements (expressed in a format conversion definition 
language known as XFlat), which can be submitted to the 'XML Convert utility', a 
program which handles a wide variety of simple format conversions. 

XML Format 

15 A recipient file in XML format comprises a number of <recipient> elements, one per 
recipient. An example of such a file 2500 (containing just one recipient) is shown in 
Fig. 24. The data in this example are described briefly below: 

• Personal Details 

20 The *<personal-details>' element includes sub-elements denoting the recipient's 

title, first name, and last name. These are used within the fax 'strip address' 
(whenever faxes are sent to the recipient) and as the first line of the postal address 
(when paper mail is sent to the recipient). An optional '<reference>' element is 
available, which may contain up to 10 characters of user-specified text that 

25 appears on job status reports generated by the message distribution system. The 

sender typically uses this element to identify the recipient by some name that is 
meaningful to him (e.g., employee number, bank account number Medicare 
number, etc.). 
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Destination Preference 

The '<tfestination-preference>' element specifies the destinations to be used for 
the recipient, and the redirection options to be invoked in case of failure. This 
element comprises one, two, or three '<attempt>' sub-elements. Each 
'<attempt>' sub-element specifies one, two, or three transmissions separated by 
spaces or commas* Each 'transmission' corresponds to an 'id' attribute in a 
'<destination>' field and thereby denotes a particular destination. The first 
transmission specified is the 'master*. In the case of fax, each 'transmission* 
includes up to three retries. 



• Destinations 

One '<destination>' element may be allowed for each medium type (as denoted 
by the 'media' attribute). If no element is provided for a particular medium, this 
means that the recipient cannot be reached by that medium. The 'id' attribute is 
1 5 used as a link to the '<attempt>' element described earlier and may comprise any 

convenient identifier. The sub-elements of the '<destination>* element specify 
the actual destination itself. 

Two styles of paper address are permitted. Fig. 24 shows the parsed form. An 
20 unparsed address can also be entered using the elements: 

• <address-line-l> </address-line-l>, 
<address-Iine-2> </adddress-line-2> 



<address-line-6> </address-line-6>. 



• Recipient Data 

The *<recipient-data>' element comprises the merge fields. In the above 
example, there is one merge field representing a single line on an invoice, and this 
contains several sub-merge-fields representing the items of information within 
30 that line. However, this is simply an example. The '<recipient-data>' field 

allows complete freedom of format (provided it contains well-formed XML). 
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VII. The Database Structure 

The message distribution system database contains a variety of tables. Fig, 25 is an 
entity relationship diagram, 2600 showing the tables and relationships. In Fig. 25, a 
5 'many to one' correspondence between database tables is denoted by 'crows feet' on the 
'many' side of the relationship. 

Each table (variously referred to as 'record' or 'entity*) and the columns (sometimes 
referred to as 'fields') within the table are described hereinafter. Every table contains a 
10 unique primary key preferably named 'xxxx_PK' (where 'xxxx' is the name of the table). 
This key is required for database replication reasons and is usually automatically 
generated. 

Customers, Accounts and Users 

15 The message distribution system has information relating to customers, accounts and 
billing preferences. The message distribution system only requires a subset of this 
information. For this reason, customers may be provided with direct online access to the 
billing system so that the customers have direct control over their accounts and billing 
preferences (and the message distribution system subset is downloaded to the message 

20 distribution system when necessary). 

Data may be duplicated manually between the message distribution system and the 
billing system. If so, the amount of such data kept within the message distribution 
system may be kept to a minimum. The message distribution system stores customer- 
25 related information as three primary entities, namely customers 2610, users 2612, and 
accounts 2614. Each customer 'owns' and administers his own group of users and 
accounts. The database tables and each field are described hereinafter. 

CUSTOMER 
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This table 2610 represents the customer and is an 'anchor point' in the database, to which 
all other entities are linked. 

customer_PK: Automatically generated unique primary key. 

5 

id: The customer identifier. This n-character (n may be 8) identifier uniquely 
identifies the customer. Each of a customer's users enter this customer id when 
the user logs on to the message distribution system. 

10 name: The customer's name (e.g., ABC Banking Corporation). This field 

appears on various screens and reports concerning the customer. 

timezone_code: Identifies the timezone within which the customer resides. 

1 5 enabled: A boolean flag that indicates whether the customer is enabled or 

disabled. A disabled customer is not allowed to access the message distribution 
system (i.e., none of the customer's users may log on). 

enabled_change time: Indicates the date/time when the 6 enabled' flag was last 
20 changed. A customer who has been disabled for a long period is deleted from 

the database. 

ftpJobSubmission: Set to * true' if this customer can submit jobs via FTP. 

25 USER 

A user record 2612 contains information about a user (i.e,, a human being who accesses 
the message distribution system). The actual name of this table in the database is 
4 USER_\ The trailing underscore character has been added to avoid conflicts with the 
SQL reserved word 'user'. 

30 

userJPK: Automatically generated unique primary key. 
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10 



id: The user identifier. This n-character (n may be 8) identifier uniquely 
identifies the user. The user must enter this user id when the user logs on to the 
message distribution system. 

name: The user name (e.g., Mary Smith). This field appeare on various screens 
and reports concerning the user. 

password: The user's password, which may be entered for log on. 
customer FK: Link to the customer who 'owns' this user. 



email, phonejiumber, fax_mimber, mobilejiumber: These fields may 
comprise contact information for the user (so that the message distribution 
1 5 system Support Team can contact the user if necessary). 

test_email, test faxjnumber, test_sms_number: These fields contain the user's 
e-mail address, fax number and SMS phone number to be used as destinations 
for test jobs. 

20 

enabled: A boolean flag that indicates whether the user is enabled or disabled. 
A disabled user is not allowed to acoess the message distribution system. 

enabled_changejime: Indicates the date/time when the 'enabled* flag was last 
25 changed. A user who has been disabled a prescribed period of time may be 

deleted from the database. 

administrator: A boolean flag that indicates whether the user is an administrator 
user or not. Administrator users have certain privileges not available to 
30 standard users. 
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ACCOUNT 

The account record 2616 contains information about an account. Each account 2616 
defines characteristics and constraints placed upon jobs run under that account. 

5 account_PK: Automatically generated unique primary key. 

name: The account name. This is a 'meaningful' name that is useful to the 
customer as a reminder of the purpose of the account. 

1 0 customer_FK: Link to the CUSTOMER record for the customer who 'owns' 

this account. 

enabled: A boolean flag that indicates whether this account is enabled or 
disabled. A disabled user is not allowed to access the message distribution 
15 system. 

enabled_change_time: Indicates the date/time when the 'enabled' flag was last 
changed. An account that has been disabled for a prescribed period of time may 
be deleted from the database. 

20 

enterprise: Indicates whether this account requires the standard or enterprise 
interface for job submission. 

product: A code that indicates the message distribution system features 
25 available under this account. 

faxcarrier, fax_carrier_user, fax_carrier_password, 
emailjsarrier, email_carrier_user, email_carrier_password 5 
srns_carrier, sras_carrier_user, sms_carrier_password, 
30 paper_cairier, paper_carrierjuser, paper_carrier ^password: 
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The 4 xxx_carrier' field contains a three-character identifier for the carrier to be 
used for medium *xxx\ Current values are: 

XPD for Xpedite, EDI for EDI Post, MSR for MessageReach, 

SMRfor SMSReach. 

5 The 'xxxjcarrier_user* and 'xxx_carrier_password s fields are used internally by 

the message distribution system when transferring files to the carrier by FTP. 
Other identifiers may be used, including for different carriers. 

fax_quality: Output quality for faxes (standard or enhanced). 

10 

fax_max_page_size: The maximum size of a fax page in bytes. 

faxcoverjpage: A boolean value indicating whether or not to generate fax 
cover pages for jobs submitted under this account. 

15 

fax_company, fax_address_l, fax_address_2, fax_address_3: The company 
name and address in these fields is printed on the cover page of each fax. 

email_from_address: The e-mail address which the message distribution 
20 system-generated e-mails reaching recipients appear to have come from. 

email-timeout: The maximum time (preferably in hours from start of job 
attempt) for which an e-mail may be outstanding. When this time is reached, all 
outstanding e-mails are assumed successful and the next attempt begins. 

25 

emailJob_status_address: The e-mail address to which job status reports are 
sent. 



USER ACCOUNT XREF 
30 This 'cross-reference' entity 2614 specifies a single valid combination of users 2612 and 
accounts 2616. For each user, this entity defines the accounts the user may specify when 
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the user submits the message distribution system job. For each account, this entity 26 14 
defines the users which may use the entity. 

user_account_xref_PK: Automatically generated unique primary key. 

5 

user_FK: Link to a USER record. 

account_FK: Link to an ACCOUNT record. 
The Job Queue 

10 The job queue exists as a set of tables within the message distribution system's relational 
database 2600. In the entity relationship diagram of Fig. 25, job queue entities are: 

2618, 2632, 2634, 2640; 2620, 2622, 2624, 2626, 2628, 2630; and 2636, 2638, 
2642, 2644, 2646, 2648, 2650, and 2652. 



15 Records 2636, 2638, 2642, 2644, 2646, 2648, 2650, 2652, 2620, 2622, 2624, 2626, 2628, 
and 2630 do not change once the job queue entry has been created whereas the records 
2618, 2632, 2634, and 2640 are updated from time to time to indicate the state of job 
processing. 

20 The records 2636, 2638, 2642, 2644, 2646, 2648, 2650 and 2652 are set up at job 

submission time. The records 2620, 2622, 2624, 2626, 2628, 2630 are also set up at job 
submission time for the standard interface but, in the case of the enterprise interface, may 
be set up by the message distribution system Support Team when the job is first 
implemented and retained across several jobs. 

25 

JOB 

At the top of the job queue hierarchy is the JOB record 2618. There is one of these for 
each job in the queue and the JOB record 2618 constitutes the 'anchor' record for all 
information related to a job. 

30 
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jobJPK: The jobid is a numeric identifier generated by the message distribution 
system, which uniquely identifies this job. The identifier appears on output 
related to the job (such as the job status report) and is displayed on the 
'confirmation screen* when the user submits a job. 

5 

user-reference: A user-generated name for the job, which is included on the 
various message distribution system/billing reports and may contain any text the 
user wishes. 

1 0 job_configuration_FK: Link to the JOB_CONFIGURATION record for this 

job. 

accountJFK: Link to the ACCOUNT record for the account under which this 
job runs. 

15 

userJFK: Link to the USER record for the user who initiated this job. 

submit_tttne: The date and time the job was submitted. 

20 fox_pnly: Means 'send faxes to all recipients with a fax address defined'. 

sms_only: Means 'send SMS messages to all recipients with an SMS address 
defined'. 

25 email_only: Means 'send e-mails to all recipients with an email address 

defined*. 

fax_preferred: Means 'send to all recipients by fax (if fax address defined); 
otherwise e-mail' . 

30 
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emaU_preferred: Means 'send to all recipients by e-mail (if e-mail address 
defined); otherwise fax' . 

job_submission_folder: The name of the folder where the various job artifacts 
5 (templates, recipient files, transmission bundle files, etc.) are stored. 

master status: Overall job status. 

master_change_time: The date and time the master status was last changed. 

10 Job Configuration Information 

The cluster of records comprising record types JOB_CONFIGURATION 2620, 
TEMPLATE 2624, TEMPLATE_ARTIFACT 2622, CONFIG_DATA 2626, 
JAVAJdAPPING JXASS JtESOURCE 2628 and JAVAJrfAPPING_CLASS 2630 
defines various artifacts and configuration used by a job. 

15 

For a job submitted using the enterprise interface, this cluster of records is defined when 
the job is first set up by the message distribution system Support Team. The cluster of 
records is used by many jobs and remains unchanged from job to job. The cluster 
includes the contents of various data files (templates, images, etc.), each of which may be 
20 'imported' into the database record as a binary object (BLOB) by the message 
distribution system Support Team when the cluster is set up. 

For a job submitted using the standard interface, this cluster of records is created at the 
time the job is submitted and is relevant for that particular job. The templates are 
25 referred to from within the cluster but are not actually stored within the database itself; 
rather the templates are held separately as a flat file. 

JOB CONFIGURATION 

This record 2620 is the 'anchor' for the job configuration record cluster. 

30 
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job_configuration_PK: Automatically generated unique primary key. 

display_name: This is a name for the job configuration that is meaningful to the 
customer and is used on the job submission screen (the 'job type') to select the 
5 job configuration. This field is only defined for enterprise interface jobs. 

enterprise: A boolean flag that indicates whether this job configuration applies 
to the enterprise or standard interface. 

10 customerJK: Link to the CUSTOMER record which 'owns' all jobs using this 

job configuration. 

TEMPLATE 

This record 2624 defines a template (i.e., a mergeahle Microsoft Word, XSL or text 
1 5 document, or a non-mergeable document in PDF, TIFF, HTML or postscript formal). 
For enterprise interface jobs, the template 2624 itself is held within this record as a 
binary image. For standard interface jobs, the template 2624 is held outside the database 
as a flat file (within the job submission folder). 

20 template_PK: Automatically generated unique primary key. 

filename: The filename of the file that constitutes this template. 

filetype: The filetype of the file that constitutes this template. 

25 

attachjiame: This name is only defined for e-mail attachment templates, and is 
the name given to the attachment file (excluding the file type) when sent to the 
recipient. 

30 media_type: Indicates the medium that this template applies to. 
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fo _rendering_engine: This is only defined for paper templates and contains the 
name of the FO rendering engine used by the message distribution system to 
produce postscript output (currently XEP or FOP). 

5 job_configuration_FK: Link to the JOB J^ONFIGURATION record. 

component Jype: Indicates which component of the final recipient message this 
template defines. For fax, this may be 'subject* or 'other 5 . For e-mail, it may 
be 'subject', 'body' or 'attachment'. For paper and SMS it is undefined 

10 

component_sequence: This is the sequence number of the component, which is 
defined if componentjype is not 'attachment*. This field represents the 
sequence number of this attachment within the message. For example, e-mail 
attachments for a four-attachment e-mail message would be numbered 1, 2, 3 
15 and 4. 

template: This field is only valid for enterprise interface templates and contains 
the template itself (For standard interface jobs, the template is kept in a flat file 
in the job submission folder.) 

20 

TEMPLATE ARTIFACT 

This record 2622 denotes images and other multimedia files iised by the TEMPLATE 
records 2624 in this JOB CONFIGURATION 2620. This record is defined for 
enterprise interface jobs (which use XSL templates). 

25 

template_artifact_PK: Automatically generated unique primary key. 

filename: The filename of the file from which this artifact was imported. 

30 filetype: The filetype of the file from which this artifact was imported 

(typically GIF or JPG). 
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job_w>nfigurationJK: Link to the JOB_CONFIGURATION record 
artifact: Contains the artifact itself 

5 

CONFIG DATA 

This record 2626 contains configuration data that is specific to a media type. The record 
is used for paper and contains information such as which paper feeder bins to use, 
10 whether to print double sided, etc. This record is defined for enterprise interface jobs. 

config _data_PK: Automatically generated unique primary key. 

filename: The filename of the file from which this config data was imported. 

15 

filetype: The filetype of the file from which this config data was imported 
(typically TXT). 

media type: Indicates the medium which this configuration data applies to. 

20 

job_configuration_FK: Link to the JOB^CONFIGURATION record. 

configuration: The configuration data itself. Fig. 26 is an example of a typical 
configuration 2700 for a paper job submitted to EDI Post. 

25 

JAVA MAPPING CLASS 

This record 2630 is mandatory and contains a Java class that is used to convert the 
recipient file to XML (possibly also making use of one or more 
JAVA_MAPPING_CLASS_RESOURCE records). Standard interface jobs use CSV- 
30 formatted recipient files, so those jobs utilise a standard java mapping class called 
'CSVMapping.class* . 
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java_mapping_class_PK: Automatically generated unique primary key. 
filename: The filename of the file from which this java class was imported. 

5 

filetype: The filetype of the file from which this java class was imported 
(typically CLASS). 

job_configuration_FK: Link to the JOB_CONFIGURATION record. 

10 

class: Contains the Java class. 
JAVA MAPPING CLASS RESOURCE 

This record 2628 is optional and contains resource objects used by the Java mapping 
1 5 class for reformatting the recipient list information. The record 2628 may contain any 
type of resource, for example, other java classes, XML stylesheets, or statements in the 
XFlat language (for input to the 'XML Convert' product). 

javajnapping_class_resource_PK: Automatically generated unique primary 
20 key. 

filename: The filename of the file from which this XFlat mapping data was 
imported. 

25 filetype: The filetype of the file from which this XFlat mapping data was 

imported. 

job_configuration_FK: Link to the JOB_CONFIGURATION record. 
30 resource data: Contains the resource itself 
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Fig. 27 shows an example 2800 of one type of resource that might be stored in this 
record. The XFlat statements converts a CSV file to XML. The CSV file comprises 
three fields per record representing 4 refho\ 'name' and 'salary*. 

5 Recipient Information 

The RECIPIENT, ATTEMPT, TRANSMISSION, MERGE_DATA, DESTINATION, 
PAPER_ADDRESS ^PARSED, PAPER_ADDRESSJJNPARSED, PHONE_NUMBER, 
and EMAIL_ADDRESS records 2636, 2638, 2640, 2642, 2644, 2652, 2650, 2648, 2646, 
respectively, define the recipient information for a job. 

10 

RECIPIENT 

Each of these records 2636 represents one recipient. 

recipient_PK: Automatically generated unique primary key. 

15 

jobJFK: Link to the JOB record for this job. 
title: The recipient's title (Mr, Mrs, Dr, etc). 
20 first_name: The recipient's first name, 

last_name: The recipient's last name. 

user_data: A user-defined data field typically used to identify this recipient 
25 from a user's perspective. 

ATTEMPT 

Up to three ATTEMPT records 263 8 may exist per recipient Each one represents one 
^ttempt^ 9 as specified in the recipient list record. The ATTEMPT records 2638 are 
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sequence numbered so that the records can be accessed in the correct order. The 
ATTEMPT record's purpose is to group the TRANSMISSION records under it. 

attempt_PK: Automatically generated unique primary key. 

5 

recipient JFK: Link to the RECIPIENT record, 
seqjaumber: Sequence number of this attempt (1 , 2 or 3). 

10 TRANSMISSION 

Up to three TRANSMISSION records 2640 may exist per attempt. Each one represents a 
transmission specified in the *<attempt>' element in the recipient list record. The 
TRANSMISSION records 2640 are sequence numbered so that the records can be 
accessed in the correct order. The first one (always sequence number 6 1 ') represents the 

1 5 master transmission (which causes redirection if it fails). 

The following fields are set up when the job is placed in the job queue: 

transmissionJPK: Automatically generated unique primary key. 

20 

destinationFK: Link to the DESTINATION record. 
attempt__FK: Link to the ATTEMPT record. 
25 account_FK: Link to the ACCOUNT record for this job. 

recipient_FK: Link to the RECIPIENT record. 

transmission J^mdieJTC: Link to the TRANSMISSION JBUNDLE record. 

30 

jobJFK: Link to the JOB record for this job. 
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attemptjno: Attempt number. 

seq_number: Sequence number of this transmission (1, 2 or 3). 

state: Indicates whether this transmission is 4 untried' (INACTIVE), 
'successfully completed* (i.e., OK) or 'unsuccessfully completed* (i.e., an error 
code). 

1 0 The remaining fields are set up when the transmission has been attempted and contain 
information relating to the success/failure of the transmission: 

job_reference: The user's reference id for the job. 

1 5 userdata: The user's reference id for this recipient 

destinationjiddress: The telephone number, e-mail address or paper address to 
which this transmission is sent. 

20 date_time job submitted: Date and time job was submitted. 

date jime_message_delivered: Date and time the message was delivered to the 
recipient. 

25 carrier_name: Name of carrier (Xpedite, etc.). 

camerjreference_id: Carrier's reference id (e.g., Xpedite's job number), 
medium: Medium to which this transmission is sent (fax, paper, etc.). 

30 

sizeofjnessage: Total size of message in bytes. 
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destination country : Country or area to which the message was delivered. 

delivery_success_failure_code: Carrier's code indicating the success or reason 
5 for failure of the transmission. 

MERGE DATA 

The merge data 2642 from the recipient record is stored here in XML text form here. 
] 0 mergedataPK: Automatically generated unique primary key. 

recipientJFK: Link to the RECIPIENT record. 

merge_data: Contains the merge data itself as a string of XML-formatted text. 

15 

DESTINATION 

For each recipient, there is a DESTINATION record 2644 for each medium (Le., a 
maximum of four). The record contains the 'media id* (indicating fax, paper, SMS or e- 
mail) and 'points to' a single 'sub-record' which is one of the following record types. 

20 

destination_PK: Automatically generated unique primary key. 

recipient_FK: Link to the RECIPIENT record. 

25 media-type: Indicates the medium which this destination denotes and thereby 

indicates the type of destination address (see below) to look for. 

PAPER ADDRESS PARSED 

This record 2652 contains an unparsed paper destination address. 

30 

paper_address_parsed_PK: Automatically generated unique primary key. 
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destinationJPK: Link to the DESTINATION record. 
street_address: Street number and name. 

5 

suburb: Suburb. 

state: State. 

10 postcode: Postcode. 

country: Country. 

PAPER ADDRESS UNPARSRD 
15 This record 2650 contains a parsed paper destination address. 

paper_address_unparsed_PK: Automatically generated unique primary key. 

destinationJFK: Link to the DESTINATION record. 

20 

address line l : Line 1 of address. 
address_line_2: Line 2 of address. 
25 address _line_3: Line 3 of address. 

address_line_4: Line 4 of address. 
address_line_5: Line 5 of address, 
address line 6: Line 1 of address. 



30 



BNSPOCID: *WO 200401 2109A1 J A> 



WO 2004/012109 PC T/AU 2003/000954 



-89- 



PHONE NUMBER 

This record 2648 contains a phone number (i.e., a destination address for SMS or fax). 
5 phonejaumber_PK: Automatically generated unique primary key. 

destination _FK: Link to the DESTINATION record. 
country_code: Country code. 

10 

area_code: Area code. 

local_number: The remainder of the phone number. 

15 EMAIL ADDRESS 

This record 2646 contains an e-mail destination address. 

email_address_PK: Automatically generated unique primary key. 

20 destinationFK: Link to the DESTINATION record. 

email_address: E-mail address. 

is_valid: A boolean value indicating whether the address syntax is valid or not. 

25 Transmission Bundle Information 

When the message distribution system processes a particular job transmission attempt, 
the system sorts the recipients into * transmission bundles' each targeted at a particular 
medium. Each transmission bundle is transmitted to a carrier and the fate of the 
transmission is eventually passed from the carrier back to the message distribution 
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system. A TRANSMISSION_BUNDLE record 2632 is created for each transmission 
bundle and is used to track its status. 

TRANSMISSION BUNDLE 
5 There is one TRANSMISSIONBUNDLE record 2632 for each transmission bundle. 
The record 2632 is created when the bundle itself is created and deleted when the job is 
finally deleted from the database. 

transmission_bundle_PK: Automatically generated unique primary key. 

job_FK: Link to the JOB record for this job. 

attempt: Sequence number of this attempt (1, 2 or 3). 

1 5 media_type: Indicates the medium for which this transmission bundle is 

destined. 

creationjime: Date and time this record was created. 

20 bundlejstatus: Processing status of this transmission bundle. See Section 5.3.1. 

status_change_time: Date and time that bundie_status was last changed. 

CARRIER REFERENCE 
25 There is one CARRIER REFERENCE record 2634 for each transmission bundle file 
sent to a carrier for a particular medium type and job id. The record 2634 is created 
when the transmission bundle file itself is created and deleted when the job is finally 
deleted from the database. 

30 In most cases, an attempt only produces one transmission bundle file per media type but 
in some cases (e.g., fax transmission bundle files destined for Xpedite and exceeding 
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1 (Mbytes), the file may be split into several separate files. For this reason, there may 
occasionally be several CARRIER_REFERENCE records 2634 per 
TRANSMISSIONBUNDLE record 2632. 

5 carrier_referenceJPK: Automatically generated unique primary key. 

transmission J>un<Ue JFK: Link to TRANSMISSION_BUNDLE record. 

carrier_id: An identifier supplied by the carrier to uniquely denote this 
1 0 transmission bundle file. This identifier may be used by the message 

distribution system to poll for feedback information from the carrier. The 
format of the field varies from one carrier to another. 

transmissionj5undle_filename: Name of the transmission bundle file. 

15 

status_collected: A boolean value which indicates whether the carrier status 
report has been received from the carrier for this transmission bundle file. If set 
to 'true' the information has been received and applied to the TRANSMISSION 
records. 

20 Miscellaneous 

NUMBER-GENERATOR 

This is a singleton record 2654 that is used to allocate unique job ids to new jobs and 
unique record keys to other records. 

25 

number_generator_PK: Automatically generated unique primary key. 
job_number: The next job id to be assigned. 
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general_number: The next general number to be assigned (used as record keys 
for all records other than JOB records). 

VIII. Java Mapping Classes and XSL Templates 
5 The message distribution system is designed as a generalised message processing engine. 
The 'core' of the message distribution system itself is designed to broadcast messages of 
any type to any destination. However, the 'job types' (aka 'job configurations') of each 
the message distribution system customer have special processing characteristics. These 
fall into two categories: 
1 0 • validating and reformatting the recipient files received from the customer, and 
• substituting merge values into merge fields in the template to generate each 
individually tailored recipient message. 

These processing categories are referred to as Java Mapping Class processing and 
15 template merge processing, respectively. These processing categories both involve 
processing that is specific to each customer and job type, and the programs/stylesheets 
for each are developed as part of the procedure for setting up a new job type on the 
system. Furthermore, the development of the programs/stylesheets may be performed by 
a development team that is separate from the team which develops the message 
20 distribution system itself. 

Fig. 28 is a block diagram of the flow of job execution illustrates how the processing path 
2900 of a job passes from the message distribution system 'core' 2910 to the Java 
Mapping Class 2930 and template 2940 and back again. 

25 

The 'core' of the message distribution system 2910 is invariant. The system software 
2910 represents a generalised platform upon which any type of the message distribution 
system job can be run. The customer-specific components 2930 and 2940 are different 
for each job type. 

30 
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In step 2920, the user submits a job to the system software 2910. The job information is 
assembled in step 2912. In the Java Mapping Class 2930, the recipient list is validated in 
step 2932. Then the recipient list is mapped in step 2934. Processing then continues in 
the system software 291 0, when the job is started in step 2914. In step 2916,the next 
5 recipient's merge data is obtained ("get"). The template 2940 substitutes the recipient's 
merge values into the template's merge fields. The messages are sent in step 2918 to 
recipients; also the next recipient's merge data is obtained in step 2916. 

Java Mapping Classes 

10 A Java Mapping Class 2930 (otherwise known as a Data Converter) is a powerful feature 
of the message distribution system 2900. This class 2930 allows a customer's recipient 
data to be supplied to the message distribution system in any format. The Java Mapping 
Class 2930 is a separate adjunct to the message distribution system 2910 itself which is 
tailored for specific customers' jobs. The class 2930 converts all customers' recipient 

1 5 lists into the message distribution system's standard format as described in Section VI. 
The class 2930 also offers the capability to make universal changes to a customer's 
recipient lists automatically. For example, a Java Mapping Class 2930 may implement a 
universal requirement such as "send by fax to all recipients in NSW but by e-mail to 
other recipients' 8 . There is one java mapping class 2930 for each job type (aka 'job 

20 configuration'), whose function is to validate 2932 recipient files received from a 
customer and to convert 2930 them into the message distribution system's standard 
recipient list format. 

The class 2930 provides two major methods, 'validate' and 'map' which are called by the 
25 message distribution system when necessary. The Java Mapping Class 2930 itself is kept 
in the database (in a JAVAJvlAPPING_CLASS record) and the various resources which 
the class needs (i.e., XFlat schemas and XSLT stylesheets) are also kept in the database 
(in JAVA_MAPPINGJXASS JtESOURCE records). 
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The Special Java Mapping Class Environment 

The class file of a Java Mapping Class is not stored within a JAR file like other the 
message distribution system classes; instead this file is kept within the database, in a 
JAVA_MAPPING_CLASS record, as part of the Job Configuration. The message 
5 distribution system automatically reads the class file into memory from the database 
whenever the class file is needed and then loads the file using a special message 
distribution system subclass of the Java ClassLoader (referred to here as the 'special 
ClassLoader'). 

10 The Java virtual machine distinguishes all classes by the ClassLoader used to load the 
classes. Classes loaded by a particular ClassLoader can only access other classes which 
are specifically designated on the 'classpath' for that ClassLoader. The Java virtual 
machine is split into separate 'worlds'. All classes that are loaded with the same 
ClassLoader can access each other directly but a class in one 'world' cannot easily access 

1 5 a class in another 'world' . The term 'world' has been coined here to describe this 
concept. 

This Java feature has been deliberately used to restrict Java Mapping Classes from 
accessing the message distribution system 'core' classes. Java Mapping Classes operate 
20 in a different 'world' from the rest of the message distribution system: 

• Core of the message distribution system classes can access all the standard Java 
SDK packages (java.io,java.util, etc.) and all the custom-developed the message 
distribution system packages. 

• Java Mapping classes can access all the standard Java SDK packages (javaio, 
25 java.util, etc.) and the special Java Mapping Class package (com.system.mapper) 

only. 

Thus, Java Mapping Classes are 'divorced' from the message distribution system and 
cannot access the message distribution system classes at all, so Java Mapping Classes can 
30 be enhanced or amended without requiring corresponding changes to the message 
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distribution system itself. This significantly simplifies system administration and 
protects the system against 'rogue' Java Mapping Classes. 

The message distribution system itself and its Java Mapping Classes can be visualised as 
5 separate 'islands 5 within the same Java virtual machine. The message distribution system 
passes arguments to the Java mapping classes using the 'reflection API' (ordinary 
method invocations do not work). 

Regarding the argument-passing mechanism, as a practical example, consider how the 
10 job information Gob id, job reference, job submission folder and recipient files) for an 
enterprise job is passed from the message distribution system to a Java Mapping Class. 

The message distribution system includes a class called 'EnteipriseJobSubmission' that 
contains all this information and more (stored in a variety of formats including simple 

1 5 strings and other the message distribution system-defined classes). An obvious strategy 
is to simply pass the EnterpriseJobSubmission object to a 'setJobSubmission' method in 
the Java Mapping Class. This fails, because the Java Mapping Class has no knowledge 
of the 'EnterpriseJobSubmission* class since the definition of this class is not included in 
the classpath supplied to the ClassLoader that was used to load the Java Mapping Class. 

20 In short, the Java Mapping Class is only aware of classes in its own 'world'; the class 
knows nothing of classes in the message distribution system's 'world'. However, each 
Java Mapping Class is aware of a class called ' Enterprise JobSubmissionData'. This class 
definition is part of the Java Mapping Class's own 'world' (and therefore is not part of 
the message distribution system's world). So, before invoking the Java Mapping Class, 

25 the message distribution system creates an instance of EnterpriseJobSubmissionData 
(using the special ClassLoader) and places the necessary data (ie, job id, job reference, 
job submission folder and recipient files) into the instance using its 'setter' methods. The 
message distribution system has to invoke these setter methods by reflection because the 
object exists in the other 'world'. The message distribution system then creates an 
30 instance of the Java Mapping Class itself (again using the special ClassLoader). Finally, 



BNSOOCIE><WO 200401 2 109Al_IA> 



WO 2WU/0121U9 



PCT/AU2(M>3/000954 



-96- 

the system passes the Enterprise JobSubmissionData object to the Java Mapping Class 
2930 using one of its 'setter' methods. 

The Java Mapping Class 2930 can access this object and store the object in one of its 
5 member variables in the usual way, because the object is within its own 'world' and all 
the objects which it contains are simple objects (Strings, Arrays, Files, etc.) that are part 
of the standard Java environment. Passing of information between the message 
distribution system and Java Mapping Classes 2930 uses the technique just described. 



10 Java Mapping Class Methods 

A Java Mapping Class for an enterprise interface job must extend the EnterpriseMapper 
class (which, in turn, extends the Mapper class) and must also implement the 
CustomMapper interface. This requires the methods shown in Table 5: 

15 TABLE 5 



Method Type 


Method Signature 


Where Defined 


Description 


public void 


setJobSubmissionData(Object 
jobSubmissionData); 


Mapper 


Set information 
about the job 


public void 


SetMappingResources(ArrayList 
mappingResources); 


Mapper 


Set information 
about mapping 
resources 
(XFlat files, 
XSL templates, 
etc.) 


public 
boolean 


validate(); 


Java Mapping 
Class 


Validate the 
recipient files 


public 
boolean 


mapO; 


Java Mapping 
Class 


Create the 
mapped 
recipient file 


public String 


GetErrorMessageO; 


Mapper 


Get error 
message text 


public String 


getEventldQ; 


Mapper 


Get event id 


public 
boolean 


isUserErrorO; 


Mapper 


True if user 
error occurred. 


public int 


getErrorCodeQ; 


Mapper 


Get error code 
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public File 


getMappedRecipientFileQ; 


EnterpriseMapper 


Get mapped 








recipient file 



Methods, systems, and computer program products have been disclosed for bulk 
communication of information to a single set of recipients via multiple delivery media 
5 based on the recipients' delivery preferences and incorporating escalation. While only a 
small number of embodiments have been described, it will be apparent to those skilled in 
the art that, in the light of this disclosure, modifications and/or substitutions may be made 
without departing from the scope and spirit of the invention. 

10 
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Claims 

We claim: 

1 . A method for bulk communication of information to recipients via 
multiple delivery media including facsimile, email, surface mail, and SMS messaging, 

5 said method including the steps of: 

receiving via a single interface information for distribution including information 
regarding recipients; and 

transmitting at least one document based on said received information using a 
specified one of said delivery media for each of said recipients based on said recipients' 
10 delivery preferences. 

2. The method according to claim 1, further including the step of escalating 
transmission of said at least one document using a different one of said delivery media 
for each of one or more of said recipients for whom transmission by said specified 

1 5 delivery media fails. 

3. The method according to claim 1, wherein said received information 
includes one or more template documents and data specific to each recipient. 

20 4. The method according to claim 3, further including the step of merging 

said one or more template documents and said data specific to each recipient to provide 
said at least one document for each of said recipients. 

5. The method according to claim 4, further including the steps of 

25 determining a document template type for each delivery media and selecting a merging 
process for said document template type. 

6. The method according to claim 5, wherein said data specific to each 
recipient is provided to said respective merging process. 

30 

7. The method according to claim 2, further including the steps of: 
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converting said at least one document into a format suitable for said specified one 
or different one of delivery media for each recipient; and 

sending said formatted document to a carrier for transmission using said specified 
one or said different one of said delivery media. 

5 

8. The method according to claim 7, further including the step of processing 
a report from said carrier regarding said transmission to provide status information 
regarding delivery of said document to each recipient. 

10 9. The method according to claim 8, wherein said escalating step is 

dependent upon said status information. 

10, The method according to claim 1 , wherein said delivery media includes 
15 archiving. 

1 1 . The method according to claim 1 , wherein said delivery media includes 
one or more new media types. 

20 12. A system for bulk communication of information to recipients via 

multiple delivery media including facsimile, email, surface mail, and SMS messaging, 

said system including: 

a single interface for receiving information for distribution including information 

regarding recipients; and 
25 means for transmitting at least one document based on said received information 

using a specified one of said delivery media for each of said recipients based on said 

recipients' delivery preferences. 

1 3 . The system according to claim 12, further including means for escalating 
30 transmission of said at least one document using a different one of said delivery media 
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for each of one or more of said recipients for whom transmission by said specified 
delivery media fails. 

14. The system according to claim 12, wherein said received information 
5 includes one or more template documents and data specific to each recipient. 

15. The system according to claim 1 4, further including means for merging 
said one or more template documents and said data specific to each recipient to provide 
said at least one document for each of said recipients. 

10 

16. The system according to claim 1 5, further including means for 
determining a document template type for each delivery media and for selecting a 
merging process for said document template type. 

15 17. The system according to claim 1 6, wherein said data specific to each 

recipient is subjected to respective merging processing. 

18. The system according to claim 13, further including: 

means for converting said at least one document into a format suitable for said 
20 specified one or different one of delivery media for each recipient; and 

means for sending said formatted document to a carrier for transmission using 
said specified one or said different one of said delivery media. 

1 9. The system according to claim 1 8, further including means for processing 
25 a report from said carrier regarding said transmission to provide status information 

regarding delivery of said document to each recipient 

20. The system according to claim 19, wherein said escalating means is 
dependent upon said status information. 

30 
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.21. The system according to claim 12, wherein said delivery media includes 
archiving. 

22. The system according to claim 1 2, wherein said delivery media includes 
5 one or more new media types. 

23. A computer program product including a computer readable medium 
having a computer program recorded therein for bulk communication of information to 
recipients via multiple delivery media including facsimile, email, surface mail, and SMS 

1 0 messaging, said computer program product including: 

computer program code means for receiving via a single interface information for 
distribution including information regarding recipients; and 

computer program code means for transmitting at least one document based on 
said received information using a specified one of said delivery media for each of said 
1 5 recipients based on said recipients' delivery preferences. 

24. The computer program product according to claim 23, further including 
computer program code means for escalating transmission of said at least one document 
using a different one of said delivery media for each of one or more of said recipients for 

20 whom transmission by said specified delivery media fails. 

25. The computer program product according to cl^im 23, wherein said 
received information includes one or more template documents and data specific to each 
recipient. 

25 

26. The computer program product according to claim 25, further including 
computer program code means for merging said one or more template documents and 
said data specific to each recipient to provide said at least one document for each of said 
recipients. 

30 
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27. The computer program product according to claim 26, further including 
computer program code means for determining a document template type for each 
delivery media and for selecting a merging process for said document template type. 

5 28. The computer program product according to claim 27, wherein said data 

specific to each recipient is subjected to respective merging processing. 

29. The computer program product according to claim 24, further including: 
computer program code means for converting said at least one document into a 
10 format suitable for said specified one or different one of delivery media for each 
recipient; and 

computer program code means for sending said formatted document to a carrier 
for transmission using said specified one or said different one of said delivery media. 

15 30. The computer program product according to claim 29, further including 

computer program code means for processing a report from said carrier regarding said 
transmission to provide status information regarding delivery of said document to each 
recipient. 

20 31. The computer program product according to claim 30, wherein said 

computer program code means for escalating is dependent upon said status information. 

32. The computer program product according to claim 23, wherein said 
delivery media includes archiving. 

25 

33. The computer program product according to claim 23, wherein said 
delivery media includes one or more new media types. 

34. A method for bulk communication of information to recipients via 

30 multiple delivery media including facsimile, email, surface mail, and SMS messaging, 
said method substantially as herein disclosed with reference to any one of Figs. 1-10 of 
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the accompanying drawings. 

35. A system for bulk communication of information to recipients via 
multiple delivery media including facsimile, email, surface mail, and SMS messaging, 

5 said system substantially as herein disclosed with reference to any one of Figs. 1-10 of 
the accompanying drawings. 

36. A computer program product for bulk communication of information to 
recipients via multiple delivery media including facsimile, email, surface mail, and SMS 

10 messaging, said computer program product substantially as herein disclosed with 
reference to any one of Figs. 1-10 of the accompanying drawings. 



BNSDOCID <WO 2OO4O1210SA1 IA> 



WO 2004/012109 



PCT/AU200J/000954 



1/54 




SUBSTITUTE SHEET (RULE 26) 

BNSOOCID. <WO 2OO4012I03AI.IA. 




BNSOOCID: <WO.^_200401210SA1JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2O03/0M954 



3/54 




WO 2004/012109 PCT/AU 2003/000954 



4/S4 




BNSOOCID: <WO 200401 2109A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU 2003/000954 



5/54 




BNSDOClD: <WO. 2004012109M..IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2OO3/0O0954 



6/54 




=z in 

rr'.H-fO t_ 
^ U L. O 

or x c_ 

w OJ o 

LJ 



BNS0OCI0: <WO 2004012109A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



7/54 



PCT/AU2003/000954 




BNSDQCIO <WO 200401 2 109A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/OH0954 



8/54 



500 



510 





L 



Recipient 
Data in XML 
Format 



5b 




5b 




5b 



2 
3 



522 



520 



Record Open 
Parenthesis 




Record Close 
Parenthesis and 
Create Group 
for Previous 
Rule Set 



524 



542 



Record Position 
After 6 - * Symbol 



548 



Finished This Round 
of Rule Processing 



und } 



FIG.Sa 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO 2004012109*1 IA> 



WO 2004/01 2 109 



PCT/AU2O0J/O00954 



9/54 



.500 



2 
3 





5a 
5? 



512 




5a' 



Load Preference 
Rule Data For 
First/Next Recipient 



I 



514 



Start Processing 
from position 
that previous 
Processing Finished 

I ~ 



NO 



Any More 
Characters? 




5c 





516 
518 



5a 



Branch Based 
on next Character 





5c 



5a' 



Which Control 
Character is it? 





5c 



540 




5c 



FIGSb 



2004012109A1 IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 




5b 



10/54 




500 

5d 




1 



526 



Letter 'F'.'EVS'.'PVA'.'C 




FIG.Sc 



BNSDOCID. <WO__2O0401210aAl IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



11/54 




1~-4sz 



528 



2**<Sz 



Add Recipient to 
Fax List 



530 




Add Recipient to 
Email List 



532 




4— <l5c 




5+<Sc 



Add Recipient to 
Encrypted Email 
List 



534 



Add Recipient to 
Surface Mailing List 



536 




6~+- <fsc 



Add Recipient to 
SMS List 



538 




7*<5c 



Add Recipient to 
Archiving List 




5*<fSc 



500 




F/GSd 



BNSDOC1D: <WO 20040 1 21 09A1JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT7AU2003/000954 



12/54 



Attempt to Send 
Email to Carrier 



600 



610 



612 





Did Error Occur 
Due to Unknown 
SMTP Server? 



Yes 




6b 




620 



Does Email 
Tracking Show 
Email as Opened? 




632 



F/G.6a 



BNSDOCID: <WO . _2004012109A1 IA» 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU200J/000954 




<u 



ro 



to 



ro-g 
cux: o 



CO o c 
h- cn 

c: (o 

QJ'F CO 

t;o a; 



LU 



(Li 



o 

■o 

>-,<u 
cz-t- 
ro.-tr 
Q-E 
Exj 
O Z) 
1—100 



~0 
vo 



VO 




BNSOOCIO: <WO 20040 12109A1 IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/OU0954 



U/54 



Messaging Job 
Submitfed 
(START) 



i 



Store Recipient 
Information to 
Database 




I 



Send Messages to 
Carrier via FTP 



I 



Receive Report 
from Carrier via 
FTP 



710 



700 



Parse Carrier 
Report and Store 
Recipient Transmission 
Results to Database 



i 



End of Transmission 




712 



7% 



M Recipient Data 



716 
718 



7b 





720 



722 



F I 0.7 a 



BNSDOCID <WO . 200401210S*1JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



75/54 



700 




726 




7a 



724 



728 



Update Status 
Recipient Database 




User Requests 
Status Report 



I 



Extract Recipient 
Data from 
Database 



730 



732 



Format Report for 
User in HTML 



f— 3 — 

User Views Report 

f 



FIG. 7b 



BNSDOCIO <WO 2004012109AIJA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2OO3/000t)54 



16/54 




BNSDOCID: <WO 200401 2 t09A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



77/54 




BNSDOCID <WO 2004012I06A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 20(14/012109 



PCT/AU2003/OMW54 



18/54 



A 

CO 

E 
as 
JO 
LJ 

en 
X 




A 



V) 
X 

co 



x 
ra 

e 

OJ 

LJ 

to 

—J 

2: 

X 



A ™ 

r*o a 

com V 

*— 2 
PI 

O £ 

OJ (o 
0> CO 



II 

cr 
o 



00 



ro 
E 

>-5 

, CO 

e-u 

X C/5 

V V 



cr 
24 
o_ 

OJ . 

f- A 
11 

e 

c x OJ 
ai p= °J 

E £ 00 

X V 
V 



CJ 
T3 
CT 
ZJ 
O 



n 

CO 



X 

ro 



11 

CO 



O 



GJ 
OJ 



A 

OJ 



CO 
X 



A 

11 fli 

^ s. 

c x 

cr o_ 

<y e 

e o 

OJ 

OJ ^TJ 

-If CO 

x v 



CO 

"oj 

ho 

_L 
To 

o 

CO 
c_ 
OJ 

a. 
* 

11 

OJ 

E 

A £ 



A A 



Ac 



« CO 

01 _li 
cz ^ 

~ CO 



CO 



CO 

"O OJ 
X 

01 <y 

^{S ro 
» Jr: cz 



CO 



CD * 



A A 
OJ A 



11 11 

01 OJ 

e e 

ro ro 

cz c 



CO 

It II 

OJ OJ 

e e 

ro ro 

cr cr 



A A £ 

CO TZJ 

* X II 

* ?- CO 

co 
cr <u 

C OJir 

u c_ ro 

I ro •— 
>a2 
2= <u E 

-a oj 

* * « 

II 11 11 

OJ OJ OJ 

e e e 

ro ro ro 
c c c: A 



I 




OJ 

oj E 
ra oj 

to *tn 

CO x 

x v 



X OJ 

oj m 



cr cdl 



_ OJ 

CO ^ 
X V/ 



cz cr cr cr 

oj ai OJ OJ 

e e e e 

oj oj OJ oj 

oj Id oj oj 

»* • • a > « a 

"O TD X3 "O 

to CO W CO 

X X X X 

V V V V 



cr cr 

OJ OJ 



OJ 



oj rr 
oj oj oj m 
55 « _g S" 



CO CO CO 
XXX 



CO 



*X3 
CO 

vvv^ 



OJ 

ex. 
x 

_qj A 

E 
o 

CO OJ 



SUBSTITUTE SHEET (RULE 26) 

BNSQOCia <WO 200401 2109A1. IA> 



WO 2004/012109 



PCT/AU2003/000954 



19/54 




A 
cu 



cu 




<u 
to 
» 

cu 



o 
"to 
co 

"e 

CO 

cz 
ro 



o 

J=3 



(I 

to 



LJ 

o 

X 

ro 



_cu 

Z3 
t_ 
I 

c: 
o 
"co 
to 

E 

CO 

c 
ro 



M 
QJ 



ro 



II 

cu 



cu 

* 

II 
cu 
to 



cm 

CO 

x3 

CO 
X 

II 
cu 

CL 



CU 



E A p 



en 1 N 



a. a « ft 



<u 
cx 



X 



x3 



II 

CU 

ro 
"c: 

CU 

e 

cu 
-a 

CO 
X 



^r: cu qj 
.2 a- 9J 

£ CO CO 

oij x 

£ v 



OJ m— 

co ro 



O "□!] u 
o CO to -o 
-q x X CO 

v v 



— cu 

CU CJ 

§ ^ 

"cu cr 
-a <u 

X "O 

— CO 

\/ x 



ai 



X A 

cu 

O S 

CO cu 
x-S 

' CO 

v * 



I 

Id 



BNSDOCID: <WO 200401210SA1.IA. 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/0OU954 



20/54 



OJ 

to 
I 

J£ 
TD 
GLi 

B 
ii 

QJ 

E 
ro 

cz 



OJ 

e 

_OJ 
~OJ 

-a 

CO 
X 



"a 

QJ 

-a 
c 

O 



II 

CO 



o 

X 

ro 



<u 

CL 

T 

JO 

•a 

OJ 



ji 

OJ 

e 

A ro 
oj A c 

c 

X QJ E 

_QJ Z3 _Qj 

CL QJ 

EQJ _14 

O CO 

w x 

^ x V 
x V 

V 



A 

* 

cn 

jo. 

"to 
-a 
<o 

X 

II 

OJ 



to 
to 

OJ 

c~ 
-a 

(O 

"ro 

e 

QJ 

* 

II 
QJ 

e 

A ra 
QJ A c 

f— c; CU 

x qj E 

QJ ZD CU 

d°-QJ 

ecu . •« 
^ tO 

O " to 
u V 
"CO 

x v 



to 
x v 



II 
to 



lj 

LJ 

o 



to 
to 

QJ 

c_ 

-o 
~a 
ro 

*ro 

E 
j 

cu 

LJ 

ra 



^ A 

CU " 

fO L_ 



to 
to 

QJ 
c_ 

XJ 

ro 



S 3 OJ QJ QJ QJ QJ 



QJ 
QJ 



to 

II 
QJ 
E 
ro 

A c 

QJ *p 



CU 



C CL 

E o 

_QJ LJ 

cj x5 

■a £ 

to ^ 

x v 



"1 

x V 



A A 



to -J-r 

CO 

CO X> 

x <2 

g_ II 



r- cn 

c c_ 
to jx 

II S 

cu a. 



JO 



5 GJ 

to "to 

II II 

QJ QJ 

e e 

ro ro 



* QJ 

c- O 

o o 

LJ CL 

II II 

QJ QJ 

E E 

ro ro 

c c= 



c: c: c: cr 

QJ QJ QJ QJ 

E £ E 

QJ QJ QJ QJ 



QJ QJ QJ QJ 

X3 X3 TJ T3 

to to co to 

X X X X 

V V V V 



I 

io 



A 



cn 

c: 



it 
to 
c_ 
Z3 

LJ 
LJ 

o 

c: 



to 

x5 
to 

X 

k 

II 

QJ 
CL 
>■» 



BNSOOCID: <WO 20040l2lOQA1JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/0009M 



21/54 




A 

A <Li 

S x A 

» § p 

t/J -12 * 

V * £ 



ii 

CO 

c 
O 

cz 



E 



1 

cu 
tr 
o 



CO 
X 

n 
cu 

CL 



QJ 

O 
LJ 
i 



fO 



X 



CO 
X 
% 

II 

<u 

Q- 



CJ 

■a 
o 

I 

to 
as 



ZD 
O 

fO 



c | ra 

JS _s- CO 

-S " x 

^ x v 

x V 
V 



II 

QJ 

E 
ro 

c: 

cu 

*c_ 

15 

to 

X 



CO 
X 

II 

CJ 



ai 
E 
cz 
II 

OJ 

e 

ro 



cu 



CO 
X 




QJ 

X 
QJ 



A A 
S- c « 



QJ 



OJ 



=3 

cr 



•H oj 



EC 



A 


A 


A 








* 


• 


« 


-a 




XJ 


QJ 


QJ 


QJ 


. t - 


L. 


c_ 


% ZD 




ZJ 


cr 


cr 


cr 


QJ 


QJ 


QJ 


C— 


* 




II 


II 


II 


QJ 


Oi 


QJ 


to 


CO 


CO 


Z3 


ZD 


ZD 



BNSDOCID; <WO 20(MOI2I09A1JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



22/S4- 




OJ 



QJ 



II 
QJ 

D1 



CO 

x5 
</> 
x 

it 

OJ 



OJ 

EE 
ro 
c 

II 

OJ 

A <2 

QJ 

QJ ZD 
ZD «Q 

QJ 4= 

to 

-a JR 
V V 



I 



QJ 
CX 

X < 
QJ M 



o E 
i_j _oj 

~c3 "qj 

tn 



V V 



T3 
QJ 



II 

n 
o 

X 

ro 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO_ 



_2004012109At JA> 



WO 2004/012109 



PCT/AU20O3/0U0954 



T3 

QJ 



23/54 



o 
JZJ 



II 

CO 



O 

X 



ii 

CO 



II 

(O 
n_ 
ZZJ 
LJ 
LJ 

o 



o 2 
*~" at 



fc A 



I 

QJ 



II 
OJ 



aj .>< 

<L) n aj 



I 

<u 
cn 

ai 
e 

ii 



fO 



QJ 



X 
QJ 



to 



tO 



?5 v 

x V 



QJ 

ZJ 



tl 
TZ3 
OJ 
X 



CO 



O 



13 

.OJ 
M — 
I 

QJ 

c_ 
<u 



II 

QJ 

e 

ra 



QJ 

aaj r 

*r=f CZT OJ 

a-ai-g 
<"1o 

tig V 
x V 



o 

LJ 



A 

QJ 



II 

-a 

QJ 
X 



QJ 

E 
ro 



QJ 



II 

QJ 

E 

A ro 

A c= 
h- c □ 

E w ra 
jri <o co 

^ x * 



! v v 



to 

to 

QJ 
LJ 
LJ 

ra 

ti 

QJ 

B 
ro 
a 

QJ 
ZD 



ro 

CO 



QJ 
Q_ 

II 
QJ 

e 

ru 

rzz 

OJ 

ZJ 
JZD 



fU 



CO 
X 



A 

QJ 



cz 



to 
"a 
to 
x 

ii 

QJ 



QJ 

e 

ra 



x 

OJ 



II 

-2 A e 

O OJ QJ 

U C U Qj 



CO 



x QJ ZD _a 

. "CJ LJ "f" 



w tO 

^ LJ -» 

Vto 



V 



cn 



to 

-a 
to 
x 

m 

II 

QJ 



CO 

to 

QJ 
LJ 
LJ 

ro 

II 

QJ 

e 

ra 

QJ 

"5 

X3 



ro 
tzj 
to 
x 



V V V 



A 



OJ 

rzz 
o 



ii 
CO 



LJ 

a 

X 

ro 
EE 



X3 
OJ 

■a 

ID 
O 
JZ3 

tr 



n 
to 
t_ 

ZD 
LJ 
LJ 

o 

X 

ra 
E 



TZJ 
QJ 
t- 

*3 

cr 

QJ 

if 
QJ 

to 

ZD 



to 
to 

X 

II 

QJ 

CL 

>^ 



•a 

QJ 

£= 

*ZD 

czr 
ou 

* 

It 
QJ 

to 
ZD 



cm cn 



to 
• • 

to 

X 

II 

QJ 
CL 



-o 

QJ 
£= 
*Z3 

Lzr 

QJ 

II 

QJ 

to 

ZD 



CJ1 

cz 



to 
■a 
to 

X 
* 

II 

QJ 

OL 



OJ 



QJ 
II 

aj 
to 

ZD 



BNSDOClD: <W0 20040 1 2 1 09A 1 J A> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



24/54 



A 



^° 

U 3 oj 



QJ 



to 

-6 
to 
x 
* 

it 

QJ 



OJ 

tl 
OJ 

E 
ru 
c 

OJ 

JO 



ro 

-a 

CO 

x 



It 

OJ 



OJ 



CD 



CO tl 
to ^ 

t_ 

to 'zz 

to 

X 11 <° 

^ 11 X 



QJ 

cx 

I A 

e qj 

p e 

V, QJ 

V ^ 
V 



tl °J 



* OJ CO • 
p OJ OJ 

d ro -♦ — 



OJ 



11 11 

QJ OJ 

E E 

ro ro 

a c 



11 



^ QJ QJ OJ 

aj "5 "5 

□ J3 n J3 

(/J h — 

ro ru ro 

« » » » « » 

to "O "CJ T3 

x to 10 to 

x x x 

V V V V 



A 

QJ 
CX 



X A 

11 

v> a 

■ to 



A 



V 



A < 
qj a_ 

OJ CD- 
CO E 

to Vi 
x -a 
— to 



A A 

C QJ 
QJ LJ 

E a 

5 QJ 

QJ O" 
XD QJ 
CO co 

x x3 
co 
w x 



OJ 

cx 

I — 
x A 

_QJ A 
E^ 

-aid 
V x 



A A 

/X QJ 
QJ Q, 

C 1 — 

94 x 
Er-Si 

OJ CL* 

to E 

tO 

X TD 
CO 



-a 

QJ 



S A 

-TS OJ 

to to 
x -tB 
to 



CT 
QJ 



tl 
QJ 

to 



SUBSTITUTE SHEET (RULE 26) 

BNSOOCID: <WO 200401 21 09At_lA> 



WO 2004/012109 



PCT/AU2003/000954 




BNSDOCID: <WO 20O401210SA1 JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU200J/000954 



26/Si 




I 



CZ 
CD 

CO 

E 

CO 

c_ 
en 
o 



> CM 
IS} CN 
^ CN 
co v- 

CO ^ 
CO 



CO 
tn 
O 
X3 



NO 

CM 
CM 



*° = CM 



lj o 
co m 

id CM 



<u 

cz 



fD 



ru CM 

> 

ru 
> 
ru 



Csj CVI 

g CM 
o 

CZ 



cu 

CZ v*- « 



QJ CU 

H 

cz cz 



CN 



BNSDOCIO: <W0 2004012109A1 JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



27/54- 




5 



BNSDOCID: <WO__20O4012109A1JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



28/54 




BNSDOCID: <WO 20040I2109A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



29/54 




OJ 



ZJ 



c 
o 

LJ 



OJ 

E 
o 

(/> 

ZD 



E 



o 

m c 
E 

< 



•a 



fO 



00 



< 



fO — > 



d 
n o 

O 



=3 

r- CL 

o 



in 
ai 
>~ 



CO 
OJ 



CO 
OJ 



c: 
o 
"co 

CO 

E 

O =3 



CO 

(75 



aj 



as 
ay 
ZD 



d 

o 

no 

XD 



OJ 

7a 

0J 
*> 

OJ 
OJ 



CO 



CO 
OJ 

>- 



OJ 



CO 
OJ 



CO 
OJ 



id 



c: 
o 



o o 



CO 

o 



0J 
CO 

o 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO_ 



_20040t2l09Al IA> 



WO 2(K)4/0121I>9 PCT/AU2003/«M>!>54 



30/54 




CJl 

o 



CO 



<u 



o 











* 












E 




wil 






LJ 






* 


ro 




cx 




* 



OJ 

re 



OJ 
CD 

to 
m 

OJ 



OJ 

to 
OJ 

cc 



<U _ c 

e 3 o 

o ^ 

-t— C— CO 

CO OJ CO 

=3 JO (U 

LS ZD (X. 



is 

id 



cz 
o 
tm 
o 



BNSOOCID:<WO 2004012109A1 IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU20U3/M0954 




OJ 



"ro 



CM 

c 



c 
ro 



m <J- 
c c: 

QJ OJ 



c: 
'ro 

21 



"no 



BNSOOCID: <WO^_2004012109A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/0O0954 



32/54- 



1800 



MENU 



Acme Engineering Pty Ltd (acme) 
Peter Williams (pwill) 



Job 

Submission 



Status Report 



Administration 



Logoff 



Users Ns |_ [ Accounts^ 



Peter Williams 



pwill 



User 

Information 

User name 
User ID 
User status 
Password 
Repeat password 

Contact Phone ( 02 99440033 
Fax 1 02 84473355 



® Enabled o Disabled 



***** 



***** 



□ 



Mobile 1 0455 345676 



Destinations 1 P" IMs ^me.com.au- 



SMS 
Fax 



0433 997766 



9577 9556 



E-mail | testmessaqes®acme.comTau" 
Accounts for which this user may submit jobs 



V. Al Invoices 



Submit 



Cancel 



Help 



FIG. 18 



SUBSTITUTE SHEET (RULE 26) 



BNSOOCID. <WO 200401 2109A1JA> 



WO 2004/012109 



PCT/AU200J/000954 




BNSDOCID: <WO__ 2004012109A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 PCT7AU2003/000954 



34/54 



< 

o 
i — 
i 

>- 
i — 

CL 
LU 



tr 
o 

LJL 



ce 
o 

CL 
LU 
Ql 

cn 

ID 
I— 
< 

in 

CD 
O 



CO 
CO 

ai 

c_ CVl 

cn LD 

° CVJ 

.£^ra"ro 
cvi m 



m 



T3 
QJ 



ra 



E 

CD 



-a 

OJ 



<CLU ~ 

-a 

CJ 



OS 



OJ 



CO 

ex 

CO 13 C— 
O O 

OU OJ 

— ><: a: 



CVJ 
CVJ 

fO 

cu nn 
m # </> °* 

cu cL-Q 
lj ET cu 

rem 



CL 



i 



2 OJ 

: 

CN 



cx 
E 

OJ, 



fO 
E 
E 

ZD 



cj 

^r: ro ra^p 
t—tl *n >^ 
jo ra 

~l 1— w 

CO 3 

co -Jrt/l 

QJ 

< — l 

co *— 1 

CO 

J3J3 u ajw 

O O CU to QJ 



CO 



cot- ^ 



QJ 



CO 



CL 
O 



CO 
CO 
QJ 

cn 
o 



< 



QJ , i Q_ 

Csl 



or*;* 

= CNJ CVJ 

£cvj CVJ 

<:<c <c 

"ro 

OJ 

a 



CVJ 
CVl 



I 

O 



CVJ< 
CVl < 

& 

LL_ 1 

t 

^: 

0( 



CVl CVl 
CVl CVJ 

I < 

UL.Q- 
I 1 



CO , 



ro 



i_n«— *~ 



m 



CO 

IS- 



OJ £ J= '^r- CO 

i I ^ ^3 oj ai mil ir\n 

-a cr.ra cz G q 

_ . cu rr: ro Z3 

QJ ra c_ ocwt » 

— l> OQ 

CO 

ai 



<u . . _ 

0^°- Li- 
no ro co t_ 

to 
QJ 



QJ 



c- c~ c_ c_ 

2:2: sis: 



00 



CO 



o 
co 

-5 cvi m 



n 
co 



QJ 



i5 alra ra 



£1 E U! (fl 



BNSDOCID: <WO__200«012109A1 IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



35/54 



OJ 



m 



I?* 

gj i 
Jz CO 

CZ 



OJ 

"J/J 



J2 
75 

•4- 

Q 

<L) 
# > 

a 

OJ 

cn 
in 



ro 
HI to 



o 
t_ 



5s 
O afro 



-itcsj 
csj m 

t i 
on q_ 

tOQ- 

I 1 
oo 



cxjcvicsr cm 
i i i i 
_jcoco _j 



i I I I 

ooo o 



CO 

GJ 4= 

GO 



o 



ro 

C/3 



CO 

^ CSJ 

o So 

lO r= JZ 

hj ^ — 

ro e 
-a EE co 



CO 

w aj 

aj e 

C a, 
<LI J= 

ra aj 



C 

<u 
E 

IZ 
u 

ro 



E 
i 



c: oj 
5 °- 

• • 

CSl 

XX 

OJ QJ 

e s 

ro ro 
55 



aj 

h 

in m 
c | 

JjX 

CJ 

ro 

ro csi o o> 

-d- -d- CSi 

■ »« 

~ rn m ^~ 

{2 csi csi o 

E i i j 

l csj 

LUX x X 



CO 

CO 

c: 



QJ 

ro 



x: zt2 ro 
O =^ CO 

CO 



- S cs, 

CO ^ ^ 

GJ .oi m £ 

Cxi E w 



BNS0OCI0: <WO 200401 21 09*1 JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/0121(19 



PCT/AU200J/000954 



36/54 



2100 



MENU 



System Control Centre (control) 

System Administrator (admin) 



Job Submission 
Status Report 
Administration 
Customers 
Job Control 



Java mapping class 



Filename [invoices JavaMappinqClass. class] | Delete 



Browse! | Import 



Job Configuration 



Console 
Proxy Setting 



Java mapping class resource- 



Filename | invoicesMapRecipients.xls | | Delete 



J I Browse 1 1 Import 



Add New JVC Recource Record 



Configuration data 



Filename rDuplexPaperConfiq.xm | (Delete 

Medium o Email O Fax O SMS ® Paper 



Browse! | Import 



Add New Confiq Data Record | 



ZH iDelete 



Template 

Filename | lnvoices.xls" 
Medium o Email o Fax OSMS ©Paper 
Type O Subject OBody ©Other 
Sequence 
Name 



E 



FO Engine [o 



Browse! I Import 



Add New Template Record 



F!G.21a 



BNSDOCID: <WO 200401 2 109A1.IA> 



t 

SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU2003/000954 



37/54 



2100 



Template artifact 



Filename [ AcmeLogo.ipg" 

i 



Delete 



Browse! Import 



Template artifact 



Filename | symbol.gif 



iDeletel 



Browse 1 1 Import 



[Add New Template Artifact Record 



Export files as a specified ZIP archive 
Zip Filepath 



C:\JobConfiquration s\systemcontrol centre-bobby-2003-05-30.zip | 



Export to Specified Zip Filepath 



Submit 




Delete 




Cancel 


Help 







FIG.21b 



SUBSTITUTE SHEET (RULE 26) 



BNSOOCID <WO.__2004012108A1.IA» 



WO 2004/012109 



PCT/AU2003/000954 



38/54 



QJ 



ro 
co 
.£ 

ro 

E 
<u 

CO 



o 

A — 
o- cn 
o 

£ i 



qj <o 
X 



* e 

II X 

Is 

oi J_ 
> c 

, Oi 

x "G 

V V 



LO 

7Er> 
cr 
"cm 
ro 

CO 
CO 
QJ 

EE 

QJ 
X 
QJ 



QJ 

ro 



o 
to 

QJ 

00 
CO 



II 
cz 

.9 
"ro 
o 

ro 
E 

QJ 
-JZI 

oo 

QJ 



_ A 
ro • 

co £ 

QJ ^ 

ra5 

^ I 

a c- 

c 75 

-■ E 

QJ 

X u» 



d 

ZD 

o 
ro 



co 
o 



A A 

QJ A 

O QJ 

C CL 

QJ >-» 

m — -O 
QJ O 

I 

-O 

o 

QJ 

o 

§1 

§ A 



— o V 



Z3 
O 

CJ 
LJ 

ro 
V 



A 

QJ 
LJ 
CZ 
QJ 
c_ 
QJ 
s— 

QJ 

I 

_a 
o 



to 

QJ 

QJ 
CL 

I 

_Q 

O 



V V 



A 

CO 
O 



A 

A ^ 



_QJ 
I 

C 
QJ 



I 



A 

QJ 

Of *cj 
QJ 



CU 

v 

co QJ 



V 

> 
to 



tr 

QJ 
QJ 



> 
CO 



□L CO 

QJ oi 



*CJ 
QJ 

I 



OJ 

QJ QJ 

1 L_ 

>^ n 

qj o 

CO £E CL 

AAA 

QJ QJ QJ 



I 



I 



I 



c c c 

QJ QJ QJ 
*OL "CL 'CL 



QJ QJ 



QJ 



V V V 



co 
.a 
o 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID. <WO 200401 2 109A1_IA> 



WO 2004/012109 



PCT7AU2003/000954 



39/54 



2400 



User 
2402 



FTP 
Re 
2404 



V 



SYSTEM SOFTWARE 
Front End 2410 



RETREVE JOB STATUS 
REPORT 2412 

Retrieve XML status report, 
format using XSL stylesheet 
and display in printer friendly 
format 




SYSTEM SOFTWARE 
Back End 2420 



t 



STATUS REPORT 
2422 

Retrieve status 
information as an 
XML document 



SUBMIT JOB USING 
THE STANDARD 
INTERFACE 2414 



1. Receive job information 
from user and upload 
recipient lists and templates 

2. Invoke 'validate' to check 
recipient list 

3. Receive submit request 
from user 

4. Invoke 'submit' to 
process request 



SUBMIT JOB USING 
THE STANDARD 
INTERFACE 2416 



1 



Receive job information 
from user and upload 
recipient lists 

2. Invoke 'validate' to check 
recipient list 

3. Receive submit request 
from user 

4. Invoke 'submit' to 
process request 



STANDARD JOB 
SUBMISSION 
PROCESSOR 
2424 

1 Validate 
Check input data 
2. Submit 
Convert recip. list 
to XML & store 
job in job queue 



-L 
-k 

i 

I 

I 



ENTERPRISE JOB 
SUBMISSION 
PROCESSOR 
2426 

1. Validate 
Check input data 

2. Submit 
Convert recip. list 
to XML & store 
job in job queue 




ft3b 



FIG.233 



BNSDOCID «WO__2004012109A1JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU20O3/000954 




23a} 



4-0/54 



2400 




(23c 




Billing records 



(23c 



JOB QUEUE 
2430 

1. Job and template 
information 

2. Recipient 
information 

3. Status 
information 



Flux 2432 



t * Event i Action 





Update 
statusi 
infor- 
mation 



Action 



STATUS 
COLLECTOR 
2434 

Recieve status 
information 
supplied by the 
carriers and 
apply it to the 



job queue 



r 23aV-J 



BUNDLE PROCESSOR 2450 




(23c 



2452 

1 



. Build one 
transmission 
bundle for 
each medium 
type 

. Initiate a 
processBundles 
thread (A.B.C 
and D) for each 
transmission 
bundle 



(23c 1 



8 




B 




(23c 



(23c 



10 




(23c 



11 




(23c 




23a> 



(23c 



F/G.23b 




3 

_4 
_5 
6 



12 




13 




BNSOOCID: <WO_ _2004012109A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AU200J/000954 



4-1/54 




2400 



23ft 






Email status 2436 








SMS status report 2438 









Paper status report 2440 







Fax status report 2442 



7 - ^ et recipient information for bundling 




B 
9 

10 
11 



Fax Transmission Bundle 2454 




Merge — ► Format — ► Transmit 


Paper Transmission Bundle 2456 




Merge — ► Format — ► Transmit | 


SMS Transmission Bundle 2458 




Merge — ► Format — ► Transmit 


E-mail Transmission Bundle 2460 




Merge — ► Format — ► Transmit 





Xpedite 
2462 



EDI Post 



SMS 
Reach 
2466 



Message 
Reach 
2468 



Carriers 



FIG.23C 



BNSDOCID: <WO 20O4O12109A1 IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/01 2 109 



PCT/AL2003/0009M 



42/54 



A 

m 
x 



CO 



QJ 

ro 
to 

* i 
ro 
E 

OJ 

-£Z 
LJ 
t/7 
— I 

s: 
x 

o 

O 
A ^ 

A "ch 
^ o 
So ™ 

H^5 



F 1 a 



QJ *C0 
X 

» • * 

r* "e 

I! X 

Is 

> c 

, QJ 

E a. 
x u 

V V 



QJ 

to 

ro 
to 

CO 
QJ 

EE 

QJ 
X 
QJ 



QJ 

ro 

3: 



o 

CO 



to 
>-> 
to 



II 

c 
_o 

7a 

o 

ra 

EE 
QJ 



CO 
QJ 
LJ 

ra 

CD- 
CO 
QJ 

ro 

o 

c: 

"to 

X 

V 



A A qj 
aj QJ c: 

- f QJ 
C_ 

QJ 



ra ^ 



ra ( — 



A V 

<o A 
ra 

— aj 

e 
ra 



v v 

A 

CM ' N 
^ <C to 



QJ 

-a 
i 



ro A 

cz 



gj 
"cl 

"lj 
QJ 

t- 

V 



OJ to 



o 

to _ 

S.v v 

V 



A A 

QJ QJ .g 

e lj v 

c ^ ro 

QJ a 
to 
t_ 

QJ 
CL 



ro QJ 
V V 




^JO 



CL 

e 

OJ 

-I — 

75 



to 

e 

CO 

x 
ra 



QJ 

e 

o 



E 
aj 

ro 



A *ra t_ A 
aj E ^ 

ro 

QJ 



aj 

L_ I 
QJ QJ 
c — i i 
QJ 



**• VI t Ml 



QJ 
LJ 

QJ 
c_ 
OJ 

4— 

OJ 

— 

A f- 
"to ro ro To 

-S v v-S 
v v 



T^A 
J 15. 



id 

LL. 



BNSOOCID: <WO J00401II09A1 IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/01 21 09 



PCT/AU2003/000954 



43/54 



vO 
OJ 



O 

<o 

II 
<u 

O 
LJ 
I 

fO 
OJ 
I_ 
fO 

Ol 

O 
LJ 



</> 

E 

CO 



H 



to 

E 
to 

ii 

fO 

E 

A c 

to .o 

O fO 

ro ^= 
c: to 
^ OJ 
CO 

-S v 



o 

V-J 

OJ 

OJ ro 

V 



oo 
oo 
o> 
i_n 

* 

II 

QJ 

E 
rr 



II 

QJ 
XD 
O 
LJ 
1 

ro 

OJ 

t_ 



X 

I so 

<u * 

o <u 
* o 

II LJ 

>< C 

ro ^ 

?- o 

ii ^ 

,C5 c 

T3 OJ 

<u jn a 
EE 

f= c= o 

O 4 — 

ro c c: 
to 

OJ 



-o 
-a 
ro 

i 

OJ 

E 
o 



ii 



OJ 

ro 

CL 

11 

ro 

OJ 




to 

CO 
OJ 



5^ 

ai zd 
OJ to 

£- 1 

"to o 



to cx 

-S v 



JQ r- 
ra ^ A 

A 

V 

s ^ 

°? A 

^JL iL A 
"ai a qj 

OJ • 

to oo 



A 

cT A 

CO 
V CL 



5 w 

.CD tO 
-i= OJ 

ro 

.c ^ 

to 

to 

OJ 



ra V 

~£ cvi 

co o 
r> cm 

A A 
o o 



A A 



t/J <=■ 
m o 
OJ 5= 



V 



id 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCI0-. «WO 20O40121O9A1 IA> 



WO 2004/012109 



PCT/AU 2003/000954 



44/54 



A 

CO 

to 
<u 

X3 
TD 

ro 
_L 
"ro 

QJ 



A 



e o 

QJ 

•!=! o 

» -CI 

■A® 
• — d 

• 0 

f 

"fD 

oj — * 

*« A 
ro 

^ 00 

OJ <U A 
G c_ /N A 

g 

-j- _L ro o 

f— ■ ru - — 
.b: c: CO 

v QJ 

V V ^ 



<u 



II 

to 
to 
<u 

ro 
* 

<u 
"cu 



A 
cn 

* . 
it 
QJ 



QJ 



T3 

I) 
CO 
CO 
OJ 

CJ 



131 



II 
or 



co 

11 
QJ 



QJ 



ro 



ro 

X3 



11 

QJ 



PS 

CO 

QJ c 



ro 



o ^ 



CO 

QJ 



CJ 
QJ 



H 
CO 
CO 

a 



ro 



fD 
I 

QJ 



I 



tl 
QJ 



QJ 

£= 



QJ 



<0 

id 



aj 

Ag'g I A 

A a-s s^-aj <y 



ra 



fD 



o>uz -1- ^= j=j 



2 to 
1 .aj ~ro 



(U — q I X3 QJ I QJ QJ 1 r-r-i QJ vZI "t~3 



- M C_ OIL- Jr-P A I t_ /vi /Tl ^ 



e S,J «£'g g£i 

V i= 

QJ 



S- g ^ V vv vv 

II 



V ^ 



c 

QJ 
QJ 



SUBSTITUTE SHEET (RULE 26) 



BNSDOC1D: <W0 



20040121 09A1.IA> 



WO 2004/012109 



PCT/AU2003/000954 




BNSQCCID: <WO ..2004012109A1_IA> 



SUBSTITUTE SHEET (RULE 26) 



WO 20(14/(112109 



PCT/AU200J/000954 



46/54 




SUBSTITUTE SHEET (RULE 26) 

BNSDOCID:«WO 20040 12 IMA 1 IA> 



WO 2004/012109 



PCT/AU2003/000954 



47/54 



A 

CO 
c- 

"qj 

e 

CO 
c_ 

o. 

I 

en 



o 
to 



A 

« 



o 



A 
cn 



QJ 
J3 

E 
=> 
c 
i 

~c 
cu 



o 

X3 



a? 



A 
>> 

O 

cu A o 
roc id 

^ cu 



-5- <u 



V A To 
2 *T r 



A „ 

2 ° A * 



XJ CM 



^ E v 



cu A 
• c 

p 



^S5a 

J A E7 



ro OJ oj 
E 

o | 

cr o 

X VJ 

O A 



CO 
Of 

"cj 
E 
ru 



cu 



A* 



to o 



_QJ A 

g 1 

•= CLI l£Z 

5 ro o 

E CL CO 



CU 



X 



cu 
V 



ru £ 

vvvvvvv vvv 

cu 



c 
A ^ 

M~ O 

t- CL 

2 1 

CL CO 
CU CO 
oj 
I L_ 
CJITD 

A S v 

f= CU I 

v^a 

CU f- 

ACU to 
c_ o 

enen?- 
to 

•OTD W 

o o cu 
u u t- 

ID f0"0 



cu 



cr 



-a 
o 



V 
> 

ID 
CO 

A A 
oj cn 



id 



BNSDOClD: <WO 20040 12 109A1JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PCT/AIJ20(IJ/000954 



48/54 



A 

* 

55= a a 

— ro 



o qj a 

M~ QJ QJ 

o u 

E o oj 

Ol 



"5 „ n 

* Ji II qj 

s-g 

QJ ^3 

<o >^ cz 

e= S QJ 
Of O E: *jj 



0{ II 
=J QJ 

IS ^ 

LU > 

i5 5= A 



A 



X 



w E ii E 
I qj qj ro 
c/> » e 
QJ " ru 
OJ 

o fu m_. a 

.*$!« 
| 

"*Z QJ 

-Sen 
X V 



it oT>- 

s as 



=s aj 
"3>* 



II Sj 

QJ ro 

J 1 A 

-3 ^_ QJ 



^ I! 

QJ 3 
EE ro 

2 > 
c: -a 

'ii * 

QJ O 



QJ 

ro "» -2 
qj ro 

ro cl> 

</) >^-a 

II m -»— 

<u£ O 
(u — j — * E ro 13 
51 Q GJ ro C3 ro Q Q 



IN. 
CM 



QJ QJ 

a a 

QJ QJ 



A 

jy A 
a 

~a qj 
£ g A 

V ~t 
^ ll. 



V V 



BNSDOClO' <W0 2004012109A1 JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 2004/012109 



PC17AU2003/000954 



49/54 




CL 

E 

OJ 



00 

id 



in 

CO 
LJ 

cn 
c 

CL 

ru 



fD 

> 
ru 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 2004012109A1 JA> 



WO 2004/01 2 109 



PCT/AU 2003/000954 



50/54 




SUBSTITUTE SHEET (RULE 26) 

6NSDCCID: <WC ... 20040 12109 A 1 IA> 



WO 2004/012109 



PCT/AU2003/000954 



51/54- 



to 
x 
to 

s 

e 

X 
* 

ro 

e 

QJ 

-5 

is* 



X 

^ — 

o 

a" 

ll. ^ .to 



cn 
o 



T3 
QJ 

c 

O 



II 

to 



O 

x 

1X3 



II 
CO 



O 

cz 
E 



QJ 



QJ 



A A 



ii 

to 



lj 

o 

X 

ro 
E 



ii 

CO 



O 

E 

i2 

QJ 

-o 

_^ 
fO 

c 
o 

to 
c_ 
QJ 
CI 

II 
QJ 

E 
ca 
cz 



A A A 



en' 



cm cn 



— to 

« QJ 
CO _ 

x 

qj <y 

CL E 

>>, ro 
-♦- c: 

«J to 



co to 
co co 

X X 
m » 

a m 

QJ QJ 
CL CL 



qj ro 

ii 



11 *. 



-to rz 



A A 



QJ 



QJ C 



fcco a 

* *: E 
o oo ro 
^ -E c 

% » x c 

o QJ 
£ E cD 

— to CO 
E-6 x 

>< CO vy 

o- x V 



QJ 



QJ C 
to QJ 

C E 



n vu 

CL to QJ 

L?? CZ E 

^ QJ _QJ 

CL OJ "O 

E to to 
o -a x 



A A 
Sz to 
x 

_S cr 

CL QJ 

E w 
o -a 

2 V 



ii ii ir 

QJ QJ QJ 

E E E 

fD ro ro 

c c: c: 



ii 

QJ 
E 

ro 

c A A 



II 

to 
n 

LJ 

o 

X 

ro 
E 



n 

CO 



LJ 
LJ 

o 



QJ 
c_ 
QJ 

QJ 



I 

CZ 
JO 

"ro 

cz 

%— 

to 

QJ 

-a 



03 

Id 



QJ 
CL 



II 
QJ 

E 
ro 

A c 



CZ CZ CZ CZ OJ 

<u ai oj <u to 

QJ QJ QJ QJ QJ x 

"qj qj qj qj Frjy 
x3 "a *o *a & a 

CO CO CO CO CO £ 
X X X X -o o 

V V V V 

V x 



QJ 

CL 

>>. 

X 
QJ 



CZ CZ 

QJ QJ 

E E 

QJ QJ 



V 



jy o- QJ 

CL QJ -U 

E to to 

4 2 v 
£ v 



CJ CO 



QJ QJ 
« » » ■ 

*a "a 
to to 

X X 

V V 



lO 
X 



to x/ 
x V 




V V 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 20040 12109A1JA> 



WO 2004/012109 



PCT/AU2003/000954 



52/54 




it 

co 



CD A 
X * 
(X3 QJ 

e 3 

*_ ?" 



OJ 

ro 
it 

QJ 
E 
ro 

LJ CLI 

-S3 

52 V 



QJ 

1= A A 



QJ 



x ^ 2 A A A 



lj 
0_ QJ 

ECO 
■ » 

o -o 
u to 

CO v , 

x V 
V 



QJ 



II 
CO 



o 

X 

ro 



CO 



O 



CO 

a 
"ro 

CO 
QJ 



U 
CO 



CD 
X 

ro 



ii 

CO 



u 

CJ 

O 

*E 
* 

cz 

.9 



CO 
QJ 

II 

QJ 

ro 
c 



A 



ii 

CO 

I A 

O V- 

X « 

ro ii 
E </> 



o lj 

» LJ 

II <Z> 
co x 

LJ C 

Ip 

*E II 

t= co 
lj 

TJ E 
CO 

x 



M 



QJ CO 

■a 

CO | 
CO ^ 

aj ro 

ii 

QJ CO 



A 



n 

CO 

u 

LJ 
LJ 

o 

X 

ra 
E 



ii 

co 
3} 



O 
cz 

E 



en 



co 

CO 
X 

II 

QJ 



QJ 

"T 

io 

cn 

QJ 

t~ 
"o 

ro 

ii 

QJ 

E 
ro 
cz 



ii n 

QJ OJ 

E E 

ro ro 

a cz 



QJ 



QJ CL 
u p p 



CO OJ 

x-a 

CO 

V 



QJ 

OJ CL 

^ E 

-a o 

CO CJ 

x-6 

— CO 



II 

OJ 
E 

A £ 

"c 

oj cz 

E °J 

oj E 

co *o 
x co 

^ X 

V V 



• ui oj 



oj 

a_ oj 
^ c 
x « S 
_?J g-"0J 

Q_ QJ -o 

E co to 
o -o x 

^ V/ 

-a x V 
co w 
x V 

V 



A A 

g_QJ C 

lj qj 

>< 3 jy jay 

QJ n-QJ qj 
a_ qj *o "o 

co CO CO 
'XX 



A 

OJ 



o -o 

LJ CO 

-a x 

£ v 



qj c 

LJ QJ 

d E 

QJ QJ 
ZD — ' 

cr 
oj -o 

CO CO 
TO X 

S v 



E 

o -o 



X3 X 

co v/ 
x V 



CO v/ 

x V 



V 



id 
cu 




SUBSTITUTE SHEET (RULE 26) 

6NSD0CID <WO 20O4O12109AI IA> 



WO 2004/012109 



PCT/AL2003/000954 



A A 



53/54 




II II 
QJ CJ 



ro ro 
cz c: 



ii ii ii 

CJ QJ QJ 

e e e 

ro ro ro 

c c c 



A 




A 



QJ 



OJ 

ZD 

cr 

QJ 
CO 

CO 
X 



(U C l. 
u QJ CJ 

c e e 

QJ _0J _QJ 
Q- OJ "5j 

www 



c c c S 

QJ QJ OJ C 

e g e <u a 

QJ QJ QJ 3 ' ' 

cr oj 



A 

QJ 
CL 



W 



o 

X 

ro 
EE 

(i 

CO 



O 

cz 



QJ 



CZ 

I 

QJ 
CZ 

o 

JCZ 
CL 

M 
QJ 



XJ 

2?" A 
a- S * 

OJ •=; "O 
II 

£ " Cir 

— 3 n Qj 

CL) c_ 
W * 

^ J QJ 

•— . 3 

"Sis 

II 

QJ x 
Q-*i 



"O 

W 



-£? QJ X 

au\. 

QJ cu 
O V 

C Rl-B 
D QJ t 
O c- =3 

u ro c 



n 

OJ 



II th 
QJ QJ 



A ro ro ro A 
cz cr 



QJ QJ QJ 



77 QJ LJ 



www 



V V 



-- ° 

^ ^ ^ w u 

v v v^-g 



_aj 

CL 



-5 Ji! 
W QJ 

x -a 
^ w 
\/ x 



QJ 

Q. QJ QJ QJ 
>< JO JZ) JZJ 

CJ L L L 

5» ^ ro ro ro 
p o-oxjo 



QJ 

£ZL 

X 
QJ 

t's 



Ja' x a 



"S A 
2."° 

oj oT 

=3 II 
QJ 

w 

-6 'EI 
w ■♦— 
x w 

*n ^ 

OJ _ 

ii 

QJ 

• CL 

ro >•» 
tzj 

QJ « 

ii ii 

QJ QJ 

e e 

ro ro 



w 
x 



QJ . 



WWW 



jz: -o x x x 
ISVVV 



CO w 

x V 



in QJ 

^* to 
V * 



V V 



fH QJ 

QJ QJ 4= 
CZ -4 — — 1 

QJ Z3 ZD _q 

za jrun ~ 

QJ 4= ^ ?I 

■a 5 03x5 

W T3"D w 

V V vv 



SUBSTITUTE SHEET (RULE 26) 



2004012109A1 JA> 



WO 2004/012109 



54/54 



PCT/Al)2(tOJ/(l(»»!)54 



A 



n 
to 

c_ 
ZD 
LJ 
LJ 

o 

X 
fD 
E 



H 

to 

LJ 

o 



-a 
cu 

-a 
c= 

o 
-a 

c 

it 

CO 



O 

X 



ii 

CO 
c_ 
ZJ 

LJ 

o 



i j- 



X A A 

3! A A 



cu 

cx 

>>. 

X A 

aj /y 

S e 

x -a 
to 

X 



V 



§-S A 

<U CL*t= 
E £ 

v — CO 
W x 



It 

CL QJ 



n 
to 



QJ 



o 



a. 
S f; 
e S 

-o x 
£ V 



to 

CO 

. (U A 

A y n 

O QJ 

CU t- LJ 

u Q-c 

CZ _ QJ 

crro aj 

OJ T3 w 



A 

QJ 



« A A A 



o-a x 



aj 

I Z 

OJ 

to QJ 
x xi 
^ to 
v/ x 



<u 



V x -a _S ^ x A 



V V 



CO ^ £ 

" = CD 

TD o c: 

(O u g 

— CO 0J 

V ^ CO 



A A 
cu 

LJ 

C if? 



CU 



X A 

cu 



&1E 
^ 5 



QJ 
CO 

-o o 

CO 
X 

to QJ 
V 

v — 
\/ x 



A 



"O — » QJ 



to 

CO 
X 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO_ 



_2004012109A1 JA> 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/AU03/00954 



CLASSIFICATION OF SUBJECT MATTER 



Int CL 7 - G06F 17/60, 17/30, 17/40, 153:00 

According to International Patent gassification (IPC) or to both national classification and IPC 



B. 



FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 

WPAT, USPTO. KEYWORDS: DISTRIBUTE, MULTICAST, DELIVER, MAIL, INTERFACE, SMS, EMAIL, FAX 

TARGET, ADVERTISING, MARKETING AND SIMILAR. 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to 
claim No. 



X,P 



WO 02/086669 A2 (ERICSSON INC.) 31 October 2002 

Whole document including page 4 lines 3 to 1 8, page 6 lines 24 to 29, page 8 lines 1 9 
to 29, page 9 line 19 to page 10 line 29, and page 12 line 1 1 to 26. 

EP 1 126394 AI (RDA INTERACTIVE LLC) 22 August 2001 . 
Whole document. 



1 to 36 



I | Further documents are listed m the continuation of Box C [x] See patent family annex 



* Special categories of cited documents; 
"A" document defining the general state of the art T 
which is not considered to be of particular 
relevance 

"E" earlier application or patent but published on or "X" 
after the international filing date 

"L" document which may throw doubts on priority "V 
\ claim(6) or which is cited to establish the 

publication date of another citation or other special 

reason (as specified) 
"0 M document referring to an oral disclosure, use, 

exhibition or other means 
*P" document published prior to the international filing 
date but later than the priority date claimed 



later document published after the international filing date or priority date 
and not in conflict with the application but cited to understand the principle 
or theory underlying the invention 

document of particular relevance; the claimed invention cannot be 
considered novel or cannot be considered to involve an inventive step 
when the document is taken alone 

document of particular relevance; the claimed invention cannot be 
considered to involve an inventive step when the document is combined 
with one or more other such documents, such combination being obvious to 
a person skilled in the art 
document member of the same patent family 



Date of the actual completion of the international search 
4 September 2003 



Date of mailing of the international search report 



1 0 SEP 2003 



Name and mailing address of the ISA/AU 

AUSTRALIAN PATENT OFFICE 
PO BOX 200, WODEN ACT 2606, AUSTRALIA 
E-mail address: pct@ipaustralia.gov.au 
Facsimile No. (02) 6285 3929 



Authorized officer 

RICHARD REED 

Telephone No : (02) 6283 7927 



Form PCT/ISA/210 (second sheet) (July 1998) 



BNSDOClD: <WO 20040 121 09A1_IA> 



INTERNATIONAL SEARCH REPORT 

Information on patent family members 



International application "No. 
PCT/AU03/00954 



This Annex lists the known "A" publication level patent family members relating to the patent documents cited in the 
above-mentioned international search report. The Australian Patent Office is in no way liable for these particulars 
which are merely given for the purpose of infonnation. 



Patent Document Cited in 
Search Report 




Patent Family Member 




WO 2002086669 


US 2002184086 






EP 1126394 


NONE 






END OF ANNEX 



Form PCI7TSA/21 0 (citation family annex) (July 1998) 

BNSPOCID:<WO 2OO4O12109A1 IA> 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 



AJ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: . : 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




□ /FADED TEXT OR DRAWING 



